Блогер Дункан Эппинг записал отличное видео по теме защиты данных кластеров отказоустойчивости средствами продукта VMware vSAN Data Protection для VMware Explore в Лас-Вегасе и Барселоне. Так как ему поступали вопросы от людей по поводу защиты данных vSAN, он решил поделиться демо на YouTube и опубликовать его в своем блоге. Ранее он выпустил несколько статей о защите данных vSAN и стал замечать, что некоторые клиенты начинают тестировать эту функцию и даже использовать её в производственных средах, где это возможно. Как мы также писали ранее, решение vSAN Data Protection доступно только только в рамках архитектуры vSAN ESA, так как она использует новые возможности создания моментальных снимков (снапшотов). Также полностью новый интерфейс был представлен в средстве управления Snap Manager Appliance. Обязательно скачайте, разверните и настройте его в первую очередь.
Собственно, само демо VMware vSAN Data Protection, которое стоит посмотреть, если вы интересуетесь защитой данных в рамках виртуальной инфраструктуры VMware vSphere и vSAN:
Недавно компания Veeam представила второй релиз бесплатного решения Veeam Hardened Repository ISO. Первая версия была выпущена еще в июне 2023 года, сейчас вышло ее обновление. Veeam Hardened ISO Repository (VHR) предназначен для облегчения создания защищённого Linux-репозитория для решения Veeam Backup and Replication, так как не каждый администратор имеет достаточный опыт работы с Linux для эффективной защиты операционной системы. Veeam предлагает инструмент, который позволяет сделать это быстро и легко. Скачивание доступно бесплатно, но поскольку это технологическое превью, этот инструмент пока не следует использовать в производственных средах. ISO позволит вам создать безопасный репозиторий с функцией неизменяемости данных (immutability).
Преимущества ISO
Главное преимущество ISO заключается в том, что вам не нужно выполнять дополнительные настройки или запускать скрипты (система уже защищена благодаря специальному установщику).
В системе нет пользователя root.
Благодаря использованию Rocky Linux в качестве основы, вы получаете 10 лет поддержки для ОС.
После выхода официальной версии вы также получите поддержку от Veeam.
Требования
Оборудование, поддерживаемое RedHat (для развертывания в производственной рекомендуется физический сервер, для лабораторных условий возможна виртуальная машина), сам ISO основан на Rocky Linux.
Те же требования к CPU и RAM, что и для Linux-репозиториев.
2 диска с объёмом не менее 100 ГБ каждый.
Поддерживается только внутреннее хранилище или напрямую подключаемое хранилище с аппаратным RAID-контроллером и кэшем записи.
UEFI должен быть активирован.
Минимальная версия Veeam - V12.2.
Veeam Hardened ISO — это загрузочный ISO-образ, разработанный для упрощения настройки Veeam Hardened Repositories. Этот новый метод доставки устраняет необходимость в глубоком знании Linux, делая его доступным для более широкой аудитории. Развертывая защищённые репозитории через этот ISO, пользователи могут значительно снизить затраты на постоянное управление и повысить безопасность своей инфраструктуры резервного копирования.
Одной из ключевых особенностей Veeam Hardened ISO является возможность создания безопасного и неизменяемого репозитория для резервного копирования. Это означает, что после записи данных в репозиторий их нельзя изменить или удалить, что защищает их от атак программ-вымогателей и других вредоносных действий. Такой уровень безопасности крайне важен в современном мире, где утечки данных и кибератаки становятся всё более частыми.
Вам предоставляется преднастроенная операционная система с автоматически применённым профилем безопасности DISA STIG. Также доступен инструмент настройки защищённого репозитория (Hardened Repository Configurator Tool), который упрощает настройку сети и позволяет изменить такие параметры, как настройки HTTP-прокси, имя хоста, пароль для пользователя vhradmin, временное включение SSH, обновление ОС и компонентов Veeam, сброс защиты от смещения времени, а также выполнять простые действия, такие как вход в систему, перезагрузка или выключение.
Ключевые особенности Veeam Hardened ISO
Упрощённое развертывание — Veeam Hardened ISO значительно упрощает процесс развертывания, позволяя пользователям настраивать защищённые репозитории без необходимости глубокого знания Linux. Эта простота в использовании гарантирует, что даже пользователи с ограниченными техническими навыками могут воспользоваться передовыми возможностями защиты данных от Veeam.
Повышенная безопасность — неизменяемость Veeam Hardened Repository гарантирует, что данные резервного копирования остаются защищёнными и не могут быть изменены. Это особенно важно в условиях атак программ-вымогателей, где целостность данных резервного копирования играет ключевую роль.
Экономическая эффективность — благодаря снижению потребности в постоянном управлении и обслуживании, Veeam Hardened ISO помогает организациям экономить на операционных расходах. Такая эффективность делает решение привлекательным для компаний любого размера.
Обратная связь сообщества — поскольку Veeam Hardened ISO на данный момент находится в статусе Community Preview, пользователи могут предоставлять обратную связь и вносить свой вклад в его развитие. Такой совместный подход помогает создать продукт, который будет соответствовать потребностям и ожиданиям сообщества Veeam.
Скачать Veeam Hardened Repository ISO можно по этой ссылке. Дефолтный пароль - VHRISO.
Veeam использует интеллектуальный анализ данных во всей своей платформе, чтобы защищать ваши критические данные, обеспечивать их целостность и помогать организациям становиться более эффективными. Veeam предоставляет не только возможности резервного копирования данных, но и видимость вашей системы резервного копирования и виртуальной среды через мониторинг и отчётность в Veeam Data Platform Advanced. Благодаря этому вы можете выявлять проблемы, которые могут снижать производительность виртуальных машин или нарушать операции резервного копирования и препятствовать восстановлению данных.
Veeam Intelligent Diagnostics, функция, входящая в состав Veeam ONE (часть пакета Veeam Data Platform Advanced), позволяет автоматически выявлять известные проблемы в конфигурации и производительности инфраструктуры резервного копирования. Активировав эту функциональность через Veeam ONE, вы получаете уведомления об общих ошибках, что позволяет вам быстрее их устранять с помощью статей из базы знаний и предлагаемых решений, что снижает риски в вашей среде и гарантирует готовность к защите или восстановлению данных в любой момент.
Сигнатуры Veeam Intelligent Diagnostics
У Veeam более 550 000 клиентов, что, если задуматься, является огромным числом. Клиенты Veeam бывают самых разных размеров и работают в различных областях. От технологических компаний до медицинских организаций, нефтегазовых компаний и образовательных учреждений — Veeam защищает огромный объём данных своих клиентов.
Клиенты используют продукты по-разному, и, изучая различные случаи поддержки, Veeam узнает много нового о типичных проблемах, с которыми они сталкиваются. Veeam создает новые сигнатуры Veeam Intelligent Diagnostics на основе того, что наблюдают сотрудники компании, например, общие ошибки конфигурации или проблемы, которые возникают только в очень специфических условиях, о которых клиент даже не мог бы подумать, как, например, проблема с производительностью.
С помощью Veeam Intelligent Diagnostics можно использовать уроки, извлечённые из этих сред, чтобы снизить риски для всех клиентов.
Как VID анализирует виртуальные среды
С помощью простого агента, установленного на сервер Veeam Backup & Replication через Veeam ONE, состояние вашей среды Veeam анализируется безопасно, при этом вы полностью контролируете свои данные. Установка на серверы Veeam выполняется в один клик (если это не было сделано при подключении к среде Veeam ONE).
При этом никакие ваши данные никогда не отправляются на серверы Veeam. Вместо этого Veeam ONE просто загружает новые сигнатуры Veeam Intelligent Diagnostics с серверов Veeam, а агент, установленный на сервере Veeam, выполняет анализ. Клиенты, использующие Veeam Data Platform Advanced и Premium, могут в любое время проверить наличие новых сигнатур через Veeam ONE Data Protection View или загрузить их напрямую с веб-сайта Veeam и импортировать на сервер Veeam ONE.
Анализ логов VID может быть настроен на ежедневный запуск, а также выполняться по запросу в любое время. На самом деле, не существует более простого способа для принятия проактивных мер по защите вашей среды Veeam Backup & Replication.
Исправляйте проблемы до того, как они повлекут последствия
Сигнатуры VID обновляются дважды в месяц и содержат множество улучшений. Помимо новых определений для обнаружения проблем, с которыми могут столкнуться клиенты Veeam, обновления также включают новые возможности и улучшения самого диагностического механизма.
Если обнаружена проблема, клиенты получают уведомления через алармы в Veeam ONE с важной информацией, которая упрощает процесс устранения проблемы. Давайте рассмотрим одну из последних сигнатур VID.
Этот пример касается задач резервного копирования на ленту, он идентифицирует причину срабатывания аларма и предлагает способы её устранения. В этом случае можно увидеть, что обновление до последней версии Veeam Backup and Replication может помочь решить проблему. Если это не помогает, вам предоставляется номер тикета Veeam Intelligent Diagnostics, чтобы упростить процесс поддержки и получить частное исправление.
В данном случае Veeam Intelligent Diagnostics предоставил правильное решение, которое требует обновления. Просто подождите установки обновления 15-20 минут, и вы больше не столкнетесь с этой проблемой. Это отличный пример того, как Veeam помогает своим клиентам действительно понять, что происходит в их среде, и избежать возможных обращений в службу поддержки.
Все клиенты Veeam Data Platform могут снизить риски в своих средах, используя Veeam Intelligent Diagnostics, и в индустрии нет ничего подобного. Veeam безопасно обрабатывает информацию из логов вашей среды непосредственно на ваших серверах Veeam. Ваши данные никогда не отправляются на сервера Veeam или куда-либо ещё.
Опираясь на опыт более чем 550 000 клиентов, Veeam постоянно обновляет определения VID и отправляет их при возникновении новых проблем и рисков, помогая клиентам устранять сложности до того, как они повлекут серьезные последствия.
Если вы уже используете Veeam Data Platform Advanced или Premium, уделите несколько минут, чтобы убедиться, что у вас установлен агент Veeam ONE. Затем вы сможете просмотреть сигнатуры Veeam Intelligent Diagnostics, зайдя в раздел Intelligent Diagnostics в секции Backup & Replication представления Alarm Management.
Если вы ещё не используете Veeam Data Platform Advanced или Premium, вы можете загрузить бесплатную пробную версию на 30 дней, чтобы протестировать функции Veeam Intelligent Diagnostics.
Этот дэшборд содержит пять различных разделов: один для мониторинга производительности ESXi и vCenter, другой для производительности виртуальных машин, третий для дисков, четвёртый для хранилищ, и последний для хостов и их IPMI. Дэшборд включает переменные, чтобы сделать его использование проще и подходящим для различных типов рабочих нагрузок. Индикаторы автоматически настраиваются в зависимости от выбранных вами хранилищ данных. Если у вас много хранилищ, рассмотрите возможность изменения параметра Min Width для Repeat Panel.
Здесь визуализуются все высокоуровневые параметры виртуальной инфраструктуры, такие как загрузка ресурсов кластера, заполненность хранилищ, состояние гипервизора и использование ресурсов виртуальными машинами:
2. VMware vSphere - Datastore
Этот дэшборд содержит два раздела: один для мониторинга производительности ESXi и vCenter, другой - для производительности виртуальных машин. Дашборд включает переменные, чтобы упростить его использование и сделать его подходящим для различных типов рабочих нагрузок. Индикаторы автоматически настраиваются в зависимости от выбранных вами хранилищ данных. Если у вас много хранилищ, рассмотрите возможность изменения параметра Min Width для Repeat Panel.
Здесь мы можем увидеть загрузку емкости датасторов, параметры чтения-записи, а также суммарные показатели для используемой и свободной емкости:
3. VMware vSphere - Hosts
Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):
4. VMware vSphere - VMs
Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:
Ну и главное - вот эта статья. Она описывает, как настроить мониторинг VMware с помощью дэшбордов Grafana, InfluxDB и Telegraf. В ней пошагово объясняется создание стека контейнеров с использованием Docker Compose, настройка InfluxDB и Telegraf для сбора метрик VMware из vCenter, а также визуализация данных в Grafana. Там подробно рассматривается использование готовых дэшбордов для ускорения процесса настройки и предлагаются советы по устранению неполадок.
Это средство было сделано энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным продуктам для мониторинга серверов ESXi и виртуальных машин. Представления SexiPanels для большого числа метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS.
Давайте посмотрим на новые возможности двух недавних релизов:
Релиз Lighthouse Point (0.99k) от 7 октября 2024
VMware Snapshot Inventory
Начиная с версии SexiGraf 0.99h, панель мониторинга «VI Offline Inventory» заменена на VMware Inventory с инвентаризацией ВМ, хостов и хранилищ данных (вскоре добавятся портгруппы и другие элементы). Эти новые панели имеют расширенные возможности фильтрации и значительно лучше подходят для крупных инфраструктур (например, с более чем 50 000 виртуальных машин). Это похоже на извлечение данных из RVtools, которое всегда отображается и актуально.
В релизе v0.99k появилось представление VM Snapshot Inventory:
Улучшения "Cluster health score" для VMware vSAN 8
Вместо того чтобы бесконечно нажимать на кнопку обновления на вкладке «Resyncing Components» в WebClient, начиная с версии SexiGraf 0.99b разработчики добавили панель мониторинга vSAN Resync:
Shell In A Box
В версии SexiGraf 0.99k разработчики добавили отдельный дэшборд Shell In A Box за обратным прокси-сервером, чтобы снова сделать отладку удобной.
Прочие улучшения:
Официальная поддержка vSphere и vSAN 8.3 API, а также Veeam Backup & Replication v12
Добавлен выбор версии в панель мониторинга VMware Evo Version
Добавлена многострочная панель в панель мониторинга репозиториев Veeam
Обработка учетных записей с очень ограниченными правами
Опция использования MAC-адреса вместо Client-ID при использовании DHCP
Добавлено имя хоста гостевой ОС в инвентаризацию виртуальных машин
Релиз St. Olga (0.99j) от 12 февраля 2024
В этой версии авторы добавили официальную поддержку новых API vSphere и vSAN 8.2, а также Veeam Backup & Replication v11+.
Новые возможности:
Поддержка Veeam Backup & Replication
Автоматическое слияние метрик ВМ и ESXi между кластерами (функция DstVmMigratedEvent в VROPS)
Количество путей до HBA
PowerShell Core 7.2.17 LTS
PowerCLI 13.2.1
Grafana 8.5.9 (не 8.5.27 из-за ошибки, появившейся в v8.5.10)
Ubuntu 20.04.6 LTS
Улучшения и исправления:
Метрика IOPS для виртуальных машин
Инвентаризация VMware VBR
История инвентаризации
Панель мониторинга эволюции версий активов VMware
Исправлено пустое значение datastoreVMObservedLatency на NFS
Различные исправления ошибок
SexiGraf теперь поставляется только в виде новой OVA-аппаратной версии, больше никаких патчей (за исключением крайних случаев). Для миграции необходимо использовать функцию Export/Import, чтобы извлечь данные из вашей предыдущей версии SexiGraf и перенести их в новую.
Актуальная версия SexiGraf доступна для бесплатной загрузки на странице Quickstart.
Memory Tiering использует более дешевые устройства в качестве памяти. В Update 3 платформа vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).
Вильям Лам написал интересный пост о выводе информации для NVMe Tiering в VMware vSphere через API. После успешного включения функции NVMe Tiering, которая была введена в vSphere 8.0 Update 3, вы можете найти полезную информацию о конфигурации NVMe Tiering, перейдя к конкретному хосту ESXi, затем выбрав "Configure" -> "Hardware" и в разделе "Memory", как показано на скриншоте ниже.
Здесь довольно много информации, поэтому давайте разберём отдельные элементы, которые полезны с точки зрения NVMe-тиринга, а также конкретные vSphere API, которые можно использовать для получения этой информации.
Memory Tiering Enabled
Поле Memory Tiering указывает, включён ли тиринг памяти на хосте ESXi, и может иметь три возможных значения: "No Tiering" (без тиринга), "Hardware Memory Tiering via Intel Optane" (аппаратный тиринг памяти с помощью технологии Intel Optane) или "Software Memory Tiering via NVMe Tiering" (программный тиринг памяти через NVMe). Мы можем получить значение этого поля, используя свойство "memoryTieringType" в vSphere API, которое имеет три перечисленных значения.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Поле Tier 0 представляет общий объём физической оперативной памяти (DRAM), доступной на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "DRAM"}).Size
Tier 1 Memory
Поле Tier 1 представляет общий объём памяти, предоставляемой NVMe-тирингом, которая доступна на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.
Примечание: Можно игнорировать термин "Unmappable" — это просто другой способ обозначения памяти, отличной от DRAM.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "NVMe"}).Size
Поле Total представляет общий объём памяти, доступный ESXi при объединении как DRAM, так и памяти NVMe-тиринга, который можно агрегировать, используя размеры Tier 0 и Tier 1 (в байтах).
Устройства NVMe для тиринга
Чтобы понять, какое устройство NVMe настроено для NVMe-тиринга, нужно перейти в раздел "Configure" -> "Storage" -> "Storage Devices", чтобы просмотреть список устройств. В столбце "Datastore" следует искать значение "Consumed for Memory Tiering", как показано на скриншоте ниже. Мы можем получить это поле, используя свойство "usedByMemoryTiering" при энумерации всех устройств хранения.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Отношение объёма DRAM к NVMe по умолчанию составляет 25% и настраивается с помощью следующего расширенного параметра ESXi под названием "Mem.TierNvmePct". Мы можем получить значение этого поля, используя либо vSphere API ("OptionManager"), либо через ESXCLI.
Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:
Вильям собрал все вышеперечисленные парметры и создал скрипт PowerCLI под названием "get-nvme-tiering-info.ps1", который предоставляет удобное резюме для всех хостов ESXi в рамках конкретного кластера Sphere (вы также можете изменить скрипт, чтобы он запрашивал конкретный хост ESXi). Это может быть полезно для быстрого получения информации о хостах, на которых NVMe-тиринг может быть настроен (или нет).
В последнем релизе VMware vSAN 8.0 Update 3, утилита vSAN IO Trip Analyzer была существенно доработана. В чем именно заключается это улучшение? Теперь IO Trip Analyzer может быть включен для нескольких ВМ одновременно. Это особенно полезно при устранении проблем с производительностью комплексного сервиса, состоящего из нескольких ВМ.
Данное улучшение позволяет вам одновременно мониторить несколько ВМ и анализировать, на каком уровне у каждой из выбранных ВМ возникает задержка (latency). Обратите внимание, что это улучшение работает как для vSAN ESA, так и для vSAN OSA.
Дункан Эппинг записал на эту тему интересное обзорное видео:
Прошло довольно много времени с момента последнего крупного выпуска RabbitMQ — версия 3.0 была запущена еще в ноябре 2012 года. Хотя ожидание следующего большого обновления могло показаться долгим, за это время произошло немало событий. Вместе с несколькими приобретениями команда VMware Tanzu RabbitMQ представила значительные функции и улучшения в промежуточных выпусках. Сегодня RabbitMQ является ключевым компонентом портфеля VMware Tanzu Data Solutions в VMware Tanzu. Приверженность Broadcom к сообществу с открытым исходным кодом также имеет важное значение, поскольку все участники основной инженерной команды являются сотрудниками Broadcom.
Неудивительно, что самая значительная функция RabbitMQ 4.0 является одновременно и нарушением обратной совместимости и в значительной степени невидима для пользователей, однако она критически важна для будущей устойчивости RabbitMQ. Как и многие другие продукты такого типа, RabbitMQ имеет хранилище метаданных в своей основе. Это хранилище используется для хранения определений топологии сообщений, пользователей, виртуальных хостов (vhosts), очередей, обменов, байндингов и параметров выполнения — оно жизненно важно для работы брокера сообщений.
Старое хранилище метаданных Mnesia использовалось столько же, сколько существует RabbitMQ. Как и следовало ожидать, за последние 17 лет в функциональности RabbitMQ произошло множество изменений, и многие функции были улучшены. Новое хранилище метаданных в RabbitMQ 4.0 (Khepri) использует тот же проверенный raft-based алгоритм, который уже несколько лет поддерживает безопасность данных в очередях Quorum Queue. Это делает систему очень устойчивой к разделению сети, что, в свою очередь, делает продукт Tanzu RabbitMQ более надежным.
Другие важные преимущества заключаются в том, что Khepri более эффективен в выполнении задач обслуживания, таких как удаление очередей или обменов, что ведет к общему улучшению производительности ядра Tanzu RabbitMQ. Эти улучшения производительности также прокладывают путь для дальнейших улучшений возможностей кластеризации Tanzu RabbitMQ. Пользователи могут включить Khepri с помощью опционального флага функции, так что никто не будет вынужден использовать эту технологию, если это не требуется. Разумеется, никаких изменений в коде не требуется при его включении, и RabbitMQ автоматически обрабатывает миграцию с Mnesia на Khepri.
Что касается производительности, в этом выпуске протокол AMQP 1.0 включен в ядро RabbitMQ. Это не означает, что старый протокол AMQP 0.9.1 не будет поддерживаться — это просто значит, что теперь можно выбрать более современный и стандартизированный протокол. Поддержка этой новой версии, опубликованной OASIS, укрепляет многопротокольный подход RabbitMQ и увеличивает его универсальность. В соответствии с другими "нативизациями" поддержка AMQP 1.0 также обеспечивает такие же улучшения производительности, которые были достигнуты при внедрении "нативного" MQTT в версиях 3.12 (MQTTv3) и 3.13 (MQTTv5).
На самом деле, пропускная способность (throughput) AMQP 1.0 между версиями 3.13 и 4.0 более чем удвоилась для классических очередей и очередей Quorum, а также для потоков. Как мы видели с нативной реализацией MQTT, такой подход к протоколам ведет к меньшему потреблению памяти на соединение. Это значит, что кластеры RabbitMQ теперь могут обрабатывать более чем в два раза больше соединений AMQP 1.0 по сравнению с предыдущими выпусками. Для получения дополнительной информации об этих улучшениях производительности, пожалуйста, ознакомьтесь с этой статьей в блоге.
Ранее пользователи не могли воспользоваться возможностями управления топологией, определенными в спецификации AMQP 1.0, что требовало заранее заданных очередей, байндингов и обменов. Такая жесткая настройка ограничивала ключевую силу RabbitMQ — его гибкие маршрутизационные возможности. Однако в версии 4.0 клиентские приложения теперь могут самостоятельно объявлять, удалять, очищать, связывать или отсоединять как очереди, так и обмены при использовании AMQP 1.0. Можно даже выполнять команду "get queue", которая предоставляет полезную информацию о лидере очереди и ее репликах в случае очередей Quorum. Эти клиентские библиотеки значительно помогают разработчикам извлекать максимум из протокола с минимальными усилиями. Например, такие функции, как подтверждения отправителя, становятся очень простыми. На сегодняшний день доступны клиенты Java и .NET, а скоро появятся и другие.
Нечасто удаление функции вызывает столько внимания, как удаление классических зеркальных очередей (Classic Mirrored Queues) в RabbitMQ. Несмотря на то, что эти старые зеркальные очереди были устаревшими более 3 лет, многие разочарованы их окончательным удалением. Хорошая новость заключается в том, что, хотя зеркалирование и было удалено, любые очереди, которые были зеркальными, не будут полностью удалены в версии 4.0, только их зеркальная часть. Также стоит отметить, что пользователям не обязательно использовать зеркалирование для публикации или потребления сообщений с конкретных узлов. Фактически, даже после удаления зеркальной очереди можно публиковать сообщения или потреблять их из очереди на любом узле в том же кластере RabbitMQ. Таким образом, приложения могут использовать те же классические очереди, что и раньше. Классические очереди продолжают поддерживаться без каких-либо изменений, нарушающих совместимость с клиентскими библиотеками. Для обеспечения дальнейшей безопасности данных реплицируемыми типами остаются очереди Quorum и потоки, обе из которых являются очень зрелыми технологиями. Дополнительную информацию о том, как мигрировать с классических зеркальных очередей на очереди Quorum, можно найти в этой статье в блоге.
Инженерная команда RabbitMQ продолжает развивать очереди Quorum, чтобы они работали быстрее и безопаснее, чем раньше. Ранее пользователи могли назначать до 255 приоритетов с помощью классических зеркальных очередей, однако это путь к полному приоритетному хаосу и путанице. В спецификации JMS для AMQP 1.0 определено всего два приоритета — нормальный и высокий.
Это то, что было реализовано в очередях Quorum для версии 4.0. Любое значение приоритета между 0 и 4 (включительно) считается нормальным приоритетом. Значения выше 4 считаются высоким приоритетом, а если издатель не указывает приоритет сообщения, предполагается значение 4 (нормальный приоритет). Что делать, если пользователям нужно больше контроля? Возможно, пришло время пересмотреть определения приоритетов сообщений. Приоритеты часто наследуются от старых систем и редко пересматриваются, как видно из спецификации JMS. Если это не удается разрешить, одним из решений является использование нескольких очередей — теперь это стало проще благодаря более быстрому времени загрузки очередей Quorum в RabbitMQ 4.0 и программной декларации AMQP 1.0. Кроме того, в очередях Quorum теперь установлено значение по умолчанию для ограничения на доставку — 20, а также приоритеты для одного активного потребителя (Single Active Consumer).
Добавлен и новый тип обмена — Random Exchange. В основном предназначен для использования в сценариях "запрос-ответ", в которых сообщения всегда доставляются в локальную очередь (чтобы уменьшить задержку при публикации). Если к тому же обмену подключено несколько локальных очередей, для доставки сообщения будет выбрана одна из них случайным образом.
Для пользователей Kubernetes добавлена новая диаграмма Helm, которая развертывает как операторы Kubernetes с открытым исходным кодом, так и коммерческие операторы кластеров и топологии Tanzu. Кроме того, теперь в определениях пользовательских ресурсов Kubernetes (Custom Resource Definitions) поддерживаются регулярные выражения, что позволяет пользователям определять диапазон виртуальных хостов (vhosts) вместо их явного объявления каждый раз.
Функции устойчивости репликации "Горячий резерв" (Warm Standby Replication) также получили улучшения в этом выпуске. В версии 3.13 был добавлен конфигурационный файл, облегчающий пользователям настройку и конфигурацию WSR, который в версии 4.0 был улучшен поддержкой списков и шаблонов для виртуальных хостов и т. д. Поддержка секретов теперь доступна через тот же конфигурационный файл, чтобы помочь обеспечить дополнительную безопасность для репликационной связи между верхним и нижним кластерами; в настоящее время поддерживается Hashicorp Vault. Пользователи также могут помечать конкретные определения shovel и federation для синхронизации в рамках процесса репликации горячего резерва. Оператор Standby Replication для Kubernetes заменен этим конфигурационным файлом, что упрощает настройку WSR независимо от среды.
Таким образом, RabbitMQ 4.0 приносит несколько ключевых улучшений, особенно в области совместимости и устойчивости. Наиболее заметное для пользователей изменение — внедрение AMQP 1.0 как основного протокола с значительными улучшениями пропускной способности и подключений. Этот выпуск и его дополнительные клиентские библиотеки открывают путь к дальнейшему развитию RabbitMQ, что позволит ему оставаться наиболее широко используемым брокером сообщений во всем мире на долгие годы.
Одним из самых больших препятствий в управлении инфраструктурой частного облака является координация с владельцами приложений для планирования временных окон обслуживания, которые соответствуют потребностям их бизнеса. К счастью, VMware vSphere с возможностями живой миграции vMotion и Storage vMotion предлагает решение этой проблемы, обеспечивая проверенные обновления инфраструктуры без простоев. Однако, даже с преимуществами vMotion, бизнес-политики могут всё равно диктовать время и выполнение определённых операций, подчёркивая необходимость минимизировать количество операций по обслуживанию, где это возможно. Уменьшая число таких операций, ИТ-команды могут минимизировать сбои, снизить затраты и повысить общую эффективность инфраструктуры.
Обновление и патчинг в одном рабочем процессе
Одним из ключевых улучшений в VMware Cloud Foundation 5.2 является новая функция под названием «Flexible Bill of Materials (BOM)», которая позволяет выбирать конкретные версии отдельных компонентов во время обновления домена рабочих нагрузок (workload domain). Это упрощает процесс обновления, сокращая количество операций по обслуживанию и минимизируя простои. В предыдущих версиях VCF процесс требовал двух операций обслуживания: одной для обновления и второй для применения асинхронного патча. Теперь же гибкий BOM в VCF 5.2 упрощает процесс, снижая административную нагрузку и потенциальные риски.
Выглядит это следующим образом (кликните на картинку, чтобы открыть анимацию):
Теперь во время процесса обновления администраторам VCF предоставляется возможность выбрать другую целевую версию компонента. Если доступны, они могут выбрать из дополнительных версий, известных как асинхронные патчи – обновления, выпущенные отдельно от списка компонентов (BOM), которые можно применить, обеспечивая большую гибкость в процессе обновления. Применимость этих асинхронных патчей определяется автоматически на основе метаданных, полученных из онлайн-репозитория. Это гарантирует, что администратору будут предложены только совместимые и актуальные патчи.
Также на эту тему есть хорошее обзорное видео от VMware:
Улучшения VCF 5.2 в управлении жизненным циклом
Помимо опции гибкого списка компонентов (BOM), VCF 5.2 вводит несколько других улучшений, упрощающих процесс обновления и развертывания. Например, администраторы VCF теперь могут применять асинхронные патчи напрямую через интерфейс SDDC Manager, что упрощает поддержание актуальности среды. Процесс развертывания доменов рабочих нагрузок также был оптимизирован: асинхронные патчи автоматически включаются, чтобы обеспечить более безопасные и актуальные новые развертывания.
VCF 5.2 также вводит новый масштабируемый подход к зеркалированию онлайн-хранилища на локальный сервер, обеспечивая легкий доступ к последним патчам и обновлениям даже в изолированных или автономных средах. Эта функция особенно полезна для организаций с жесткими требованиями безопасности или ограниченным доступом к интернету, так как она гарантирует, что последние патчи и обновления всегда доступны для развертывания.
На ресурсе Technopedia вышла статья с интригующим заголовком "Cloud Exit: 42% of Companies Move Data Back On-Premises". Интересно узнать, что такой большой процент компаний, оказывается, перемещают свои данные обратно из облака в онпремизную инфраструктуру.
Почему набирает популярность тренд «выход из облака»?
Простыми словами, «выход из облака» — это тренд, при котором компании оптимизируют свою зависимость от облачных сервисов и пересматривают свои расходы на облако, либо планируя полный отказ от облака, либо сокращая его использование. Значительная часть компаний активно пересматривает свои обязательства по использованию облачных решений.
Фактически, 94% респондентов, участвовавших в этом недавнем опросе, были вовлечены в проекты, связанные с частичным отказом от облака.
Как отмечается в подробной статистике по облачным расходам, высокая стоимость облачных решений оказалась серьезным сдерживающим фактором для корпораций. Более 43% ИТ-руководителей заявили, что перенос приложений и данных из локальной инфраструктуры в облако оказался дороже, чем ожидалось.
Одним из первых известных случаев «выхода из облака» был пример Dropbox в 2015 году, когда компания сократила операционные расходы на 74,6 миллиона долларов за два года. Несмотря на начальные преимущества масштабируемости и гибкости облачных решений, быстрый рост Dropbox сделал постоянные расходы на облако неприемлемыми.
Некоторые компании растут настолько быстро, что для них имеет смысл создать собственную инфраструктуру с использованием кастомных технологий и отказаться от облака. При этом выход из облака помог им снизить зависимость от облачных сервисов крупных поставщиков, таких как Amazon и Google, за счет использования собственных технологий и создания собственной сети.
Выход из облака: ключевая статистика
42% организаций в США рассматривают возможность или уже переместили как минимум половину своих облачных рабочих нагрузок обратно в собственную инфраструктуру.
94% респондентов опроса участвовали в каком-либо проекте, связанном с частичным отказом от облака.
43% ИТ-руководителей считают, что перенос приложений и данных в облако оказался дороже, чем ожидалось.
Dropbox сэкономил 74,6 миллиона долларов за два года, сократив использование облачных сервисов.
Basecamp потратил 3,2 миллиона долларов на облачные сервисы в 2022 году и прогнозирует экономию 7 миллионов долларов за пять лет, перейдя на локальную инфраструктуру.
В настоящее время доля рынка Amazon Web Services составляет 31%, Microsoft Azure — 25%, Google Cloud — 11%.
«Облако — не благотворительность»
Вице-президент Dropbox по инженерным вопросам и бывший инженер Facebook Адитья Агарвал отметил, что, несмотря на экономию на крупных операциях, облачные провайдеры не предоставляют услуги по себестоимости — они не передают все сэкономленные средства клиентам.
Агарвал сказал: «Никто не ведет облачный бизнес как благотворительность». Когда компании достигают таких масштабов, при которых создание собственной инфраструктуры становится экономически выгодным, это позволяет значительно сэкономить, устранив «облачного посредника» и связанные с этим расходы.
Тем не менее, облако, конечно, не «просто чей-то компьютер», как гласит шутка. Оно принесло огромную пользу тем, кто смог к нему адаптироваться.
Но, как и искусственный интеллект (AI), облачные технологии мифологизировали и преувеличивали как универсальный инструмент для повышения эффективности — романтизировали до такой степени, что повсеместные мифы о его рентабельности, надежности и безопасности побуждали компании без раздумий внедрять их. Эти мифы часто обсуждаются на высоких уровнях, формируя восприятие, которое не всегда соответствует реальности, что приводит к тому, что многие компании принимают решения, не полностью учитывая потенциальные недостатки и реальные проблемы.
Более того, небольшое количество гигантских корпораций с монополистическими тенденциями управляют рынком облачных технологий и влияют на все: от ценообразования до технологических инноваций. Такое неравномерное распределение рыночной силы может подавлять конкуренцию и ограничивать оперативную гибкость, вынуждая компании пересматривать свои облачные стратегии.
Мечты об облаке vs. реальность
В 2019 году Gartner смело предсказала, что 80% предприятий закроют свои традиционные центры обработки данных к 2025 году и перейдут в облако, но насколько это предсказание верно?
Всего три года спустя, в отчете Accenture за 2022 год был представлен неоднозначный прогресс. Хотя девять из десяти компаний признают значительные выгоды от своих инвестиций в облако, только 42% полностью реализовали свои ожидаемые результаты, и лишь 32% считают свои облачные проекты завершенными и удовлетворительными.
Учитывая разрыв между идеализированным восприятием облачных технологий и их фактическим функционированием, компании должны подходить к облаку с более взвешенной перспективой. Давайте разберемся, что такое выход из облака, почему компании оптимизируют облачные решения и как монополистические практики замедляют инновации.
Основные причины отказа от облака
Компании всё чаще пересматривают свои обязательства по использованию облака и изучают возможности стратегий отказа от него. Вот ключевые факторы, которые способствуют изменению настроений на рынке:
1. Финансовые соображения
Все говорят о том, как переход в облако снижает капитальные затраты и устраняет необходимость в физических серверах и оборудовании. И хотя это может быть правдой на первых порах, долгосрочные операционные расходы на облако часто оказываются неожиданно высокими.
Один из примеров — известный поставщик решений для управления проектами Basecamp, чьи ежемесячные расходы на облако достигли примерно $180 000, когда они обнаружили, что услуги облачных провайдеров, таких как Amazon и Google, оказались дороже и сложнее, чем ожидалось.
Потратив $3,2 млн на облачные сервисы в 2022 году, компания подсчитала, что использование локального оборудования будет стоить $840 000 ежегодно. Отказавшись от этого финансового бремени, Basecamp прогнозирует экономию $7 млн за пять лет.
Такая ситуация не уникальна. Многие организации обнаруживают, что постоянные расходы, связанные с облачными сервисами, особенно в отношении масштабирования и хранения данных, могут превышать затраты на поддержку локальной инфраструктуры.
Когда преимущества масштабируемых облачных сервисов уменьшаются, компании с предсказуемым спросом на данные приходят к выводу, что высокая цена за гибкость облачных решений становится неоправданной.
2. Непредсказуемые расходы и избыточность облачных ресурсов
Расходы, которых можно избежать, и избыточные облачные ресурсы стали другой важной проблемой, выявленной в опросе «Стратегия облака 2023» от Hashicorp. 94% респондентов сообщили о ненужных расходах из-за неиспользуемых облачных ресурсов.
Эти расходы часто связаны с поддержанием простаивающих ресурсов, которые не обслуживают реальные операционные нужды компании. Такие раздутые расходы не только не способствуют росту бизнеса, но и отвлекают средства от потенциальных зон развития.
3. Уязвимости в безопасности
Согласно глобальному опросу PwC «Надежды и страхи сотрудников» за 2024 год, около 47% технических лидеров считают облачные угрозы основной проблемой в сфере кибербезопасности. Распространено мнение, что локальная инфраструктура менее безопасна, поскольку она физически доступна.
Но действительно ли это так, или все дело в том, насколько хорошо контролируется доступ? Правда в том, что удаленный доступ значительно увеличивает вероятность кибератак, так как количество потенциальных точек входа для хакеров растет. Кроме того, облако является привлекательной целью для злоумышленников. Более 80% утечек данных в 2023 году были связаны с данными, хранящимися в облаке, а средняя глобальная стоимость утечки составила $4,45 млн.
Крупные компании, такие как Capital One, Twilio, Pegasus Airlines и Uber, в прошлом сталкивались с утечками через AWS. Эти громкие случаи усилили опасения по поводу хранения конфиденциальных данных в облаке.
4. Проблемы с производительностью и надежностью
Проблемы с надежностью, особенно связанные с перебоями в работе облачных сервисов, могут временно остановить бизнес-процессы. Для компаний, достигших масштаба, при котором простой означает значительные финансовые потери, риск перебоев делает облачные услуги менее привлекательными.
Зависимость от одного поставщика и ограниченная гибкость — серьезные проблемы, с которыми сталкиваются компании, пытающиеся использовать облачные сервисы. С долей рынка в 31% у Amazon Web Services, 25% у Microsoft Azure и 11% у Google Cloud, небольшое количество крупных провайдеров доминирует на рынке.
Из-за такой концентрации власти эти компании получают почти монопольный контроль не только над ценообразованием и условиями предоставления услуг, но и над гибкостью управления технологической инфраструктурой бизнеса. Это также позволяет этим гигантам несправедливо продвигать свои собственные приложения и сервисы, что затрудняет конкуренцию для сторонних решений.
Очевидно, что неконтролируемое доминирование на облачном рынке может замедлить технологические инновации. В феврале 2024 года Google усилил критику Microsoft, предупредив, что стремление Microsoft к облачной монополии может затормозить развитие технологий следующего поколения, таких как AI, и призвал к государственному вмешательству.
Выход из облака или переход на другие сервисы не всегда проходит гладко. Поскольку провайдеры полностью управляют облачной инфраструктурой, клиенты имеют ограниченный контроль над внутренними операциями. Во время отказа или миграции они часто сталкиваются с потенциальными уязвимостями в безопасности, высокими расходами и сложностями в перенастройке.
Хотя издержки на выход из облака постепенно становятся менее серьезной проблемой в 2024 году, соглашения с конечными пользователями (EULA) и политика управления со стороны провайдеров могут еще больше ограничить свободу операций.
Все эти факторы увеличивают риски, связанные с облачными технологиями. Компании должны подходить к облачным решениям с тщательно продуманной стратегией, чтобы извлечь выгоду, не став заложниками своих технологий.
Вильям Лам написал интересную статью о поддержке технологии Intel Neural Processing Unit (NPU) на платформе VMware ESXi.
Начиная с процессоров Intel Meteor Lake (14 поколения), которые теперь входят в новый бренд Intel Core Ultra Processor (серия 1), встроенный нейронный процессор (Neural Processing Unit, NPU) интегрирован прямо в систему на кристалле (system-on-chip, SoC) и оптимизирован для энергоэффективного выполнения AI-инференса.
Хотя вы уже можете использовать интегрированную графику Intel iGPU на таких платформах, как Intel NUC, с ESXi для инференса рабочих нагрузок, Вильяму стало интересно, сможет ли этот новый нейронный процессор Intel NPU работать с ESXi?
Недавно Вильям получил доступ к ASUS NUC 14 Pro (на который позже он сделает подробный обзор), в котором установлен новый нейронный процессор Intel NPU. После успешной установки последней версии VMware ESXi 8.0 Update 3, он увидел, что акселератор Intel NPU представлен как PCIe-устройство, которое можно включить в режиме passthrough и, видимо, использовать внутри виртуальной машины.
Для тестирования он использовал Ubuntu 22.04 и библиотеку ускорения Intel NPU, чтобы убедиться, что он может получить доступ к NPU.
Шаг 1 - Создайте виртуальную машину с Ubuntu 22.04 и настройте резервирование памяти (memory reservation - это требуется для PCIe passthrough), затем добавьте устройство NPU, которое отобразится как Meteor Lake NPU.
Примечание: вам нужно будет отключить Secure Boot (этот режим включен по умолчанию), так как необходимо установить более новую версию ядра Linux, которая всё ещё находится в разработке. Отредактируйте виртуальную машину и перейдите в VM Options -> Boot Options, чтобы отключить его.
Когда Ubuntu будет запущена, вам потребуется установить необходимый драйвер Intel NPU для доступа к устройству NPU, однако инициализация NPU не удастся, что можно увидеть, выполнив следующую команду:
dmesg | grep vpu
После подачи обращения в поддержку Github по поводу драйвера Intel NPU, было предложено, что можно инициализировать устройство, используя новую опцию ядра, доступную только в версии 6.11 и выше.
Шаг 2 - Используя эту инструкцию, мы можем установить ядро Linux версии 6.11, выполнив следующие команды:
После перезагрузки вашей системы Ubuntu вы можете убедиться, что теперь она использует версию ядра 6.11, выполнив команду:
uname -r
Шаг 3 - Теперь мы можем установить драйвер Intel NPU для Linux, и на момент публикации этой статьи последняя версия — 1.8.0. Для этого выполните следующие команды:
Нам также нужно создать следующий файл, который включит необходимую опцию ядра (force_snoop=1) для инициализации NPU по умолчанию, выполнив следующую команду:
Теперь перезагрузите систему, и NPU должен успешно инициализироваться, как показано на скриншоте ниже.
Наконец, если вы хотите убедиться, что NPU полностью функционален, в библиотеке Intel NPU Acceleration есть несколько примеров, включая примеры малых языковых моделей (SLM), такие как TinyLlama, Phi-2, Phi-3, T5 и другие.
Для настройки вашего окружения Python с использованием conda выполните следующее:
Автор попробовал пример tiny_llama_chat.py (видимо, тренировочные данные для этой модели могли быть основаны на изображениях или художниках).
Независимо от того, используете ли вы новую библиотеку Intel NPU Acceleration или фреймворк OpenVino, теперь у вас есть доступ к ещё одному ускорителю с использованием ESXi, что может быть полезно для периферийных развертываний, особенно для рабочих нагрузок, требующих инференса AI, и теперь с меньшим энергопотреблением.
Следующий пример на Python можно использовать для проверки того, что устройство NPU видно из сред выполнения, таких как OpenVino.
from openvino.runtime import Core
def list_available_devices():
# Initialize the OpenVINO runtime core
core = Core()
# Get the list of available devices
devices = core.available_devices
if not devices:
print("No devices found.")
else:
print("Available devices:")
for device in devices:
print(f"- {device}")
# Optional: Print additional device information
for device in devices:
device_info = core.get_property(device, "FULL_DEVICE_NAME")
print(f"\nDevice: {device}\nFull Device Name: {device_info}")
if __name__ == "__main__":
list_available_devices()
Компания Broadcom выпустила интересное видео, где Mark Achtemichuk и Uday Kulkurne обсуждают оптимизацию AI/ML нагрузок с использованием аппаратной платформы NVIDIA GPU и решения VMware Cloud Foundation:
Производительность и эффективность виртуализации графических процессоров (GPU) является одним из ключевых направлений для разработки решений в области искусственного интеллекта (AI) и машинного обучения (ML).
Виртуализация AI/ML задач, работающих на GPU, представляет собой вызов, так как традиционно считается, что виртуализация может значительно снижать производительность по сравнению с «чистой» конфигурацией на физическом оборудовании (bare metal). Однако VMware Cloud Foundation демонстрирует почти аналогичную производительность с минимальными потерями за счет умной виртуализации и использования технологий NVIDIA.
Рассматриваемые в данном видо графические процессоры от NVIDIA включают модели H100, A100 и L4, каждая из которых имеет уникальные характеристики для обработки AI/ML задач. Например, H100 оснащен 80 миллиардами транзисторов и способен ускорять работу трансформеров (на основе архитектуры GPT) в шесть раз. Особенностью H100 является возможность разделения GPU на несколько независимых сегментов, что позволяет обрабатывать задачи параллельно без взаимного влияния. A100 и L4 также обладают мощными возможностями для AI/ML, с небольшими различиями в спецификациях и применимости для графических задач и машинного обучения.
VMware Cloud Foundation (VCF) позволяет использовать все преимущества виртуализации, обеспечивая при этом производительность, близкую к физическому оборудованию. Одна из ключевых возможностей — это поддержка дробных виртуальных GPU (vGPU) с изоляцией, что позволяет безопасно распределять ресурсы GPU между несколькими виртуальными машинами.
Используя виртуализированные конфигурации на базе VCF и NVIDIA GPU, компании могут значительно снизить общие затраты на владение инфраструктурой (TCO). VMware Cloud Foundation позволяет консолидировать несколько виртуальных машин и задач на одном физическом хосте без существенной потери производительности. Это особенно важно в условиях современных датацентров, где необходимо максимизировать эффективность использования ресурсов.
В серии тестов было проверено, как виртуализированные GPU справляются с различными AI/ML задачами по сравнению с физическим оборудованием. Используя стандартные бенчмарки, такие как ML Commons, было показано, что виртуализированные GPU демонстрируют производительность от 95% до 104% по сравнению с bare metal конфигурациями в режиме инференса (вычисления запросов) и около 92-98% в режиме обучения. Это означает, что даже в виртуализированной среде можно добиться почти той же скорости, что и при использовании физического оборудования, а в некоторых случаях — даже превзойти её.
Основное преимущество использования VMware Cloud Foundation с NVIDIA GPU заключается в гибкости и экономии ресурсов. Виртуализированные среды позволяют разделять ресурсы GPU между множеством задач, что позволяет более эффективно использовать доступные мощности. Это особенно важно для компаний, стремящихся к оптимизации капитальных затрат на инфраструктуру и повышению эффективности использования серверных мощностей.
На конференции VMware Explore 2024, вместе с презентацией новой версии платформы VMware Cloud Foundation 9, Broadcom также объявила о планах разработки следующего поколения VMware vSphere Virtual Volumes (vVols). Следующее поколение vVols будет преследовать три основные цели: обеспечить согласованный и оптимизированный пользовательский опыт на разных платформах хранения, адаптировать vVols для современных масштабируемых задач, таких как рабочие нагрузки AI/ML и развёртывания облачных провайдеров, а также полностью интегрироваться с VMware Cloud Foundation (VCF).
vVols использует управление на основе политик хранилищ (Storage Policy-Based Management, SPBM) для оптимизации операций и минимизации потребности в специализированных навыках для работы с инфраструктурой хранения. vVols устраняет необходимость в ручном предоставлении хранилища, заменяя это описательными политиками на уровне ВМ или VMDK, которые могут быть применены или обновлены через простой рабочий процесс.
Клиенты продолжают активно внедрять VMware Cloud Foundation, и они хотят интегрировать свои существующие решения для хранения в VCF, чтобы максимизировать свою отдачу от инвестиций. Они стремятся начать путь к полностью программно-определяемому подходу к инфраструктуре, упрощая операции хранения и интегрируясь с облачными возможностями управления, встроенными в частную облачную платформу VCF. По мере того, как клиенты запускают всё больше рабочих нагрузок на массивы, поддерживающие vVols, требования к производительности, масштабу и защите данных продолжают расти, поэтому vVols должен развиваться, чтобы удовлетворять эти потребности.
Планируемые преимущества следующего поколения vVols для клиентов включают:
Полная интеграция с VMware Cloud Foundation: установка, развертывание и управление хранилищем с VCF, пригодность для использования в качестве основного и дополнительного хранилища для всех доменов рабочих нагрузок.
Прописанная модель VASA для обеспечения согласованного и оптимизированного пользовательского опыта на всех платформах хранения.
Поддержка масштабируемых сценариев использования для облаков.
Обеспечение высокой доступности и развертывания с растянутыми кластерами.
Бесшовная миграция с платформы vVols без простоев.
Масштабируемые, неизменяемые снимки (immutable snapshots) как для традиционных, так и для современных приложений.
Для получения дополнительной информации о планируемых нововведениях vSAN и vVols рекомендуем посмотреть записи вот этих сессий VMware Explore 2024:
VMware’s Vision for Storage and Data Protection in VMware Cloud Foundation [VCFB2086LV]
What’s New with vSAN and Storage Operations in VMware Cloud Foundation [VCFB2085LV]
vVols and Stretched Clusters with Pure Storage and VMware [VCFB2397LVS]
Workload Provisioning And Protection Made Easy With VMware And NetApp [VCFB2433LVS]
В рамках анонсов конференции Explore 2024, касающихся VMware Private AI Foundation с NVIDIA (PAIF-N), в компании VMware решили обновить Improved RAG Starter Pack v2.0, чтобы помочь клиентам воспользоваться новейшими микросервисами для инференса NVIDIA (модули NIM), которые обеспечивают атрибуты промышленного уровня (надёжность, масштабируемость и безопасность) для языковых моделей, используемых в системах Retrieval Augmented Generation (RAG).
Следуя духу оригинального Improved RAG Starter Pack (v1.0), Broadcom предлагает серию Jupyter-блокнотов, реализующих улучшенные методы поиска. Эти методы обогащают большие языковые модели (LLMs) актуальными и достоверными контекстами, помогая им генерировать более точные и надёжные ответы на вопросы, связанные с специализированными знаниями, которые могут не быть частью их предобученного датасета. Благодаря этому можно эффективно снизить "галлюцинации" LLM и повысить надёжность приложений, управляемых AI.
Новые функции обновлённого Improved RAG Starter Pack:
Используются NVIDIA NIMs для LLM, текстовых встраиваний и ранжирования текстов — трёх основных языковых моделей, которые питают RAG-пайплайны.
Обновили LlamaIndex до версии v0.11.1.
Используются Meta-Llama3-8b-Instruct в качестве генератора LLM, который управляет RAG-пайплайном.
Заменили OpenAI GPT-4 на Meta-Llama-3-70b-Instruct как движок для DeepEval для выполнения двух ключевых задач, связанных с оценкой RAG-пайплайнов:
Для оценки ("судейства") RAG-пайплайнов путём оценки ответов пайплайна на запросы, извлечённые из набора для оценки. Каждый ответ оценивается по нескольким метрикам DeepEval.
Анатомия улучшенного RAG Starter Pack
Каталог репозитория GitHub, содержащий этот стартовый пакет, предоставляет пошаговое руководство по внедрению различных элементов стандартных систем RAG.
Помимо NVIDIA NIM, системы RAG используют такие популярные технологии, как LlamaIndex (фреймворк для разработки приложений на основе LLM), vLLM (сервис для инференса LLM) и PostgreSQL с PGVector (масштабируемая и надёжная векторная база данных, которую можно развернуть с помощью VMware Data Services Manager).
Все начинается с реализации стандартного RAG-пайплайна. Далее используется база знаний RAG для синтеза оценочного набора данных для оценки системы RAG. Затем улучшается стандартная система RAG за счет добавления более сложных методов поиска, которые будут подробно описаны далее. Наконец, различные подходы RAG оцениваются с помощью DeepEval и сравниваются для выявления их плюсов и минусов.
Структура каталога организована следующим образом.
Теперь давайте обсудим содержание каждой секции.
Настройка сервисов NIM и vLLM (00)
Эта секция содержит инструкции и скрипты для Linux shell, которые необходимы для развертывания сервисов NVIDIA NIM и vLLM, требуемых для реализации RAG-пайплайнов и их оценки.
Инициализация PGVector (01)
Эта секция предлагает несколько альтернатив для развертывания PostgreSQL с PGVector. PGVector — это векторное хранилище, которое будет использоваться LlamaIndex для хранения базы знаний (текстов, встраиваний и метаданных), что позволит расширить знания LLM и обеспечить более точные ответы на запросы пользователей.
Загрузка документов базы знаний (02)
Каждый демо-пример RAG и введение в RAG используют базу знаний для расширения возможностей генерации LLM при вопросах, касающихся областей знаний, которые могут не входить в предобученные данные моделей. Для этого стартового пакета VMware выбрала десять документов из коллекции электронных книг по истории от NASA, предлагая таким образом вариант типичных документов, часто используемых в туториалах по RAG.
Загрузка документов в систему (03)
Эта секция содержит начальный Jupyter-блокнот, где используется LlamaIndex для обработки электронных книг (формат PDF), их разбиения на части (узлы LlamaIndex), кодирования каждого узла в виде длинного вектора (встраивания) и хранения этих векторов в PostgreSQL с PGVector, который действует как наш векторный индекс и движок запросов. На следующем изображении показан процесс загрузки документов в систему.
После того как PGVector загрузит узлы, содержащие метаданные, текстовые фрагменты и их соответствующие встраивания, он сможет предоставить базу знаний для LLM, которая будет генерировать ответы на основе этой базы знаний (в нашем случае это книги по истории от NASA).
Генерация оценочного набора данных (04)
Jupyter-блокнот в этой папке демонстрирует использование Synthesizer из DeepEval для создания набора данных вопросов и ответов, который впоследствии будет использоваться метриками DeepEval для оценки качества RAG-пайплайнов. Это позволит определить, как изменения ключевых компонентов пайплайна RAG, таких как LLM, модели встраиваний, модели повторного ранжирования, векторные хранилища и алгоритмы поиска, влияют на качество генерации. Для синтетической генерации оценочного набора данных используется модель Meta-Llama-3-70b-Instruct.
Реализация вариантов RAG (05)
В этом каталоге содержатся три подкаталога, каждый из которых включает Jupyter-блокнот, исследующий один из следующих вариантов реализации RAG-пайплайна на основе LlamaIndex и открытых LLM, обслуживаемых через vLLM:
Стандартный RAG-пайплайн + повторное ранжирование: этот блокнот реализует стандартный RAG-пайплайн с использованием LlamaIndex, включая финальный этап повторного ранжирования, который управляется моделью ранжирования. В отличие от модели встраиваний, повторное ранжирование использует вопросы и документы в качестве входных данных и напрямую выдаёт степень схожести, а не встраивание. Вы можете получить оценку релевантности, вводя запрос и отрывок в модель повторного ранжирования. VMware использует следующие микросервисы NVIDIA (NIM) для работы RAG-системы:
Генератор LLM для RAG: Meta-Llama-3-8b-Instruct
Модель встраиваний для RAG: nvidia/nv-embedqa-e5-v5
Модель повторного ранжирования для RAG: nvidia/nv-rerankqa-mistral-4b-v3
Следующая картинка иллюстрирует, как работает эта RAG-система.
Извлечение с использованием окон предложений:
Метод извлечения с использованием окон фраз (Sentence Window Retrieval, SWR) улучшает точность и релевантность извлечения информации в RAG-пайплайнах, фокусируясь на определённом окне фраз вокруг целевой фразы. Такой подход повышает точность за счёт фильтрации нерелевантной информации и повышает эффективность, сокращая объём текста, обрабатываемого во время поиска.
Разработчики могут регулировать размер этого окна, чтобы адаптировать поиск к своим конкретным задачам. Однако у метода есть потенциальные недостатки: узкая фокусировка может привести к упущению важной информации в соседнем тексте, что делает выбор подходящего размера окна контекста критически важным для оптимизации как точности, так и полноты процесса поиска. Jupyter-блокнот в этой директории использует реализацию SWR от LlamaIndex через модуль Sentence Window Node Parsing, который разбивает документ на узлы, каждый из которых представляет собой фразу. Каждый узел содержит окно из соседних фраз в метаданных узлов. Этот список узлов повторно ранжируется перед передачей LLM для генерации ответа на запрос на основе данных из узлов.
Автоматическое слияние при извлечении:
Метод автоматического слияния при извлечении — это подход RAG, разработанный для решения проблемы фрагментации контекста в языковых моделях, особенно когда традиционные процессы поиска создают разрозненные фрагменты текста. Этот метод вводит иерархическую структуру, где меньшие текстовые фрагменты связаны с более крупными родительскими блоками. В процессе извлечения, если определённый порог меньших фрагментов из одного родительского блока достигнут, они автоматически сливаются. Такой подход гарантирует, что система собирает более крупные, связные родительские блоки, вместо извлечения разрозненных фрагментов. Ноутбук в этой директории использует AutoMergingRetriever от LlamaIndex для реализации этого варианта RAG.
Оценка RAG-пайплайна (06)
Эта папка содержит Jupyter-блокнот, который использует DeepEval для оценки ранее реализованных RAG-пайплайнов. Для этой цели DeepEval использует оценочный набор данных, сгенерированный на предыдущем шаге. Вот краткое описание метрик DeepEval, используемых для сравнения различных реализаций RAG-пайплайнов. Обратите внимание, что алгоритмы метрик DeepEval могут объяснить, почему LLM присвоил каждую оценку. В нашем случае эта функция включена, и вы сможете увидеть её работу.
Contextual Precision оценивает ретривер вашего RAG-пайплайна, проверяя, расположены ли узлы в вашем контексте поиска, которые релевантны данному запросу, выше, чем нерелевантные узлы.
Faithfulness оценивает качество генератора вашего RAG-пайплайна, проверяя, соответствует ли фактический вывод содержимому вашего контекста поиска.
Contextual Recall оценивает качество ретривера вашего RAG-пайплайна, проверяя, насколько контекст поиска соответствует ожидаемому результату.
Answer Relevancy измеряет, насколько релевантен фактический вывод вашего RAG-пайплайна по отношению к данному запросу.
Hallucination — эта метрика определяет, генерирует ли ваш LLM фактически корректную информацию, сравнивая фактический вывод с предоставленным контекстом. Это фундаментальная метрика, так как одной из главных целей RAG-пайплайнов является помощь LLM в генерации точных, актуальных и фактических ответов на запросы пользователей.
Оценки DeepEval были выполнены с использованием следующей конфигурации:
LLM-оценщик, оценивающий метрики DeepEval: Meta-Llama-3-70b-Instruct, работающая на vLLM в режиме guided-JSON.
Следующая таблица показывает результаты оценки из одного из экспериментов VMware, который включал более 40 пар вопросов и ответов.
Следующая диаграмма представляет другой ракурс взгляда на предыдущий результат:
Как показывает таблица, конкретная реализация RAG может показывать лучшие результаты по определённым метрикам, что указывает на их применимость к различным сценариям использования. Кроме того, метрики оценки помогают определить, какие компоненты ваших RAG-пайплайнов нуждаются в корректировке для повышения общей производительности системы.
Заключение
Обновлённый RAG Starter Pack предоставляет ценный инструментарий для тех, кто внедряет системы RAG, включая серию хорошо документированных Python-блокнотов, предназначенных для улучшения LLM за счёт углубления контекстного понимания. В этот пакет включены передовые методы поиска и такие инструменты, как DeepEval, для оценки системы, которые помогают снизить такие проблемы, как "галлюцинации" LLM, и повысить надёжность ответов AI. Репозиторий на GitHub хорошо структурирован и предлагает пользователям понятное пошаговое руководство, которому легко следовать, даже если вы не являетесь специалистом в области данных. Клиенты и партнёры Broadcom, использующие PAIF-N, найдут этот пакет полезным для запуска приложений на базе генеративного AI в инфраструктурах VMware Cloud Foundation. Ожидайте новых статей, в которых VMware рассмотрит ключевые аспекты безопасности и защиты в производственных RAG-пайплайнах.
В этом году на VMware Explore 2024 в Лас-Вегасе компания VMware представила новую версию платформы Tanzu Platform 10. Этот новый релиз предназначен для современных предприятий и направлен на трансформацию управления, обеспечения безопасности и оптимизации приложений с улучшенной гибкостью и возможностями мониторинга. Tanzu Platform 10 позволяет выбирать между Cloud Foundry и Kubernetes в качестве среды выполнения, будь то в публичных или частных облаках. Такая гибкость обеспечивает возможность адаптации Tanzu Platform под конкретные нужды вашего бизнеса. Если вы используете Cloud Foundry, теперь вы можете также подключиться и к экосистеме Kubernetes и воспользоваться надежной интеграцией данных, продолжая использовать уникальные функции Cloud Foundry. Вы также получите более глубокую видимость своих систем благодаря улучшенному пользовательскому интерфейсу и усовершенствованиям в области безопасности, циклов развертывания и создания приложений с поддержкой GenAI.
Давайте рассмотрим, что можно ожидать от Tanzu Platform 10 для приложений, работающих в средах Cloud Foundry.
GenAI для Tanzu Platform теперь в публичной бета-версии
Проект, начавшийся на хакатоне на прошлом VMware Explore, вырос в публичную бета-версию GenAI для Tanzu Platform, запущенную в июне. В VMware рады представить еще больше функций и обновлений в последней публичной бета-версии, включая дополнительные возможности для разработчиков, чтобы быстрее и эффективнее создавать приложения в Tanzu Platform для Cloud Foundry.
На волне успеха GenAI в Tanzu Platform компания VMware объявляет о новых возможностях, которые помогут текущим и будущим клиентам Tanzu Platform создавать корпоративные приложения с поддержкой GenAI. VMware Tanzu AI Solutions — это революционный набор возможностей, доступных в Tanzu Platform, который поддерживает организации в ускорении и масштабировании безопасной поставки интеллектуальных приложений.
Последние функции, доступные в публичной бета-версии, включают:
Поддержку VMware vSphere, Google Cloud Platform, AWS и Azure
Безопасный и приватный доступ к совместимому с OpenAI API через Tanzu AI Server
Брокер для моделей, работающих на VMware Private AI Foundation и моделях сторонних поставщиков
Развертывание частных больших языковых моделей (LLM) через BOSH в вашей инфраструктуре Tanzu Platform для Cloud Foundry
Поддержка открытых моделей через vLLM и Ollama, а также поддержка доступа к приватным или ограниченным репозиториям Hugging Face
Поддержка Nvidia GPU (vGPU и режим pass-through) и Intel Xeon CPU (производительность может варьироваться в зависимости от модели и поколения процессора)
Мультиинфраструктурная видимость теперь доступна в Tanzu Platform для Cloud Foundry
Tanzu Platform 10 предоставляет сквозной мониторинг, позволяя командам платформ отслеживать весь жизненный цикл приложений. От начальных коммитов кода до развертывания в продакшн, вы получите полное представление о производительности, ошибках и использовании ресурсов.
В последнем релизе Tanzu Platform 10 теперь поддерживаются мультиинфраструктурные представления и улучшенная видимость Tanzu Platform для Cloud Foundry, что позволяет инженерам платформ видеть все свои системы и компоненты в одном месте. Это упрощает устранение проблем со "здоровьем приложений" во всех развертываниях Cloud Foundry, включая дополнительные возможности для встраивания проверок здоровья в Tanzu Platform.
Интерфейс Tanzu Platform hub, который объединяет инфраструктуры в едином представлении:
Функции, которые будут доступны в Tanzu Platform for Cloud Foundry 10, включают:
Просмотр всех платформ (Multi-foundation view): Tanzu Platform предоставляет возможность видеть все ваши платформы в одном консолидированном представлении. Это объединение упрощает управление приложениями на различных платформах, предлагая более четкую картину всей вашей экосистемы.
Снижение затрат (Cost Savings): Используя интегрированное представление центра Tanzu Platform, команды платформ могут сэкономить деньги за счет сокращения потребности в сторонних продуктах. Эта интеграция не только снижает затраты, но и упрощает операции, повышая эффективность и контроль вашего бизнеса.
Метрики в одном представлении (At-a-glance metrics): Интуитивно понятная панель управления Tanzu Platform предлагает простые метрики для всех платформ. Эта функция позволяет быстро оценить состояние всей вашей среды Cloud Foundry, включая количество приложений и сервисов, работающих на каждой платформе. Этот всеобъемлющий обзор обеспечивает своевременное выявление и устранение проблем.
В сегодняшней среде ограничение угроз безопасности имеет первостепенное значение. Tanzu Platform 10 делает акцент на прозрачной модели безопасности, позволяя командам четко видеть и понимать действующие меры безопасности. Это облегчает обнаружение уязвимостей и соблюдение требований, при этом сохраняется целостность ваших приложений.
Теперь в Tanzu Platform 10 клиенты могут анализировать список компонентов программного обеспечения (SBOM) своих приложений, чтобы выявлять устаревшие библиотеки и быстро предоставлять разработчикам информацию о том, какие действия необходимо предпринять для обновления кода приложения. Это также позволяет инженерам платформ поддерживать актуальность библиотек и обеспечивать непрерывные обновления платформы для снижения рисков безопасности.
Быстрее циклы развертывания с улучшенными возможностями для разработчиков
В основе работы VMware с сообществом лежит поддержка разработчиков. Tanzu Platform 10 представляет улучшенные возможности для разработчиков, предлагая надежные инструменты и интеграции, которые упрощают процесс разработки.
В Tanzu Platform 10 канареечные и прокатные развертывания помогут клиентам улучшить опыт развертывания, повысить продуктивность и ускорить циклы развертывания. Канареечные развертывания позволяют тестировать новую сборку на небольшом объеме пользователей, сохраняя старую сборку для большей части трафика.
Клиенты также могут оценить улучшения в автоматическом масштабировании приложений благодаря переработанной архитектуре CF CLI. Автоматическое масштабирование приложений можно применять к еще большему количеству приложений для увеличения времени запуска и улучшения общей устойчивости приложений.
Непрерывные обновления, сертификации и улучшения платформы
Клиенты могут ожидать более плавных обновлений, более легкого отслеживания процесса ротации сертификатов и многочисленных улучшений платформы, разработанных для повышения удобства использования и производительности. Эти улучшения позволяют вашей платформе оставаться на переднем крае инноваций и быть готовой к удовлетворению меняющихся требований бизнеса.
Также дополнительные сведения о VMware Tanzu Platform 10 вы можете узнать тут и тут.
На конференции Explore 2024 в Лас-Вегасе компания VMware представила VMware Cloud Foundation 9 – решение, которое упростит переход от разрозненных ИТ-сред к единой, интегрированной платформе частного облака. VMware Cloud Foundation 9 сделает развертывание, использование и управление безопасным и экономичным частным облаком быстрее и проще, чем когда-либо прежде.
Упрощение развертывания и эксплуатации современной инфраструктуры
VMware Cloud Foundation 9 (VCF 9) разрабатывается с целью упростить процесс развертывания и эксплуатации современной инфраструктуры. Она позволит организациям управлять всей своей инфраструктурой как единым, унифицированным комплексом.
Эта возможность помогает удовлетворить потребности современных приложений, интегрируя передовые функции VMware в платформу частного облака. Основная платформа VCF улучшена за счет набора новых сервисов, что расширяет области ее применения, повышает безопасность и поддерживает комплексную экосистему для разработки приложений.
VCF отвечает потребностям двух ключевых групп: команд инфраструктуры, отвечающих за создание и поддержку ИТ-сред, и потребителей инфраструктуры, таких как инженеры платформ и ученые данных, которые используют эти среды для запуска приложений.
Для команд инфраструктуры VCF 9 предлагает унифицированную платформу, которая автоматизирует и упрощает операции, позволяя эффективно развертывать среды частного облака.
Но давайте уделим внимание тому, как решается задача удовлетворения потребностей разных ролей в различных ИТ-средах.
Расширение возможностей как для администраторов облака, так и для инженеров платформы
Для облачных администраторов VCF 9 предложит упрощенный подход к управлению инфраструктурой. Новая централизованная консоль предоставляет единый обзор среды, позволяя администраторам управлять емкостями и арендаторами, настраивать политики управления и получать доступ к комплексной панели безопасности — все в одном месте.
Включение таких функций, как диагностика VCF и анализ топологии приложений и сети, позволит быстрее решать проблемы и оптимизировать производительность, превращая повседневное управление из рутины в простую организованную операцию.
Для инженеров платформ VCF 9 предлагает среду, готовую к использованию, поддерживающую традиционные виртуальные машины, Kubernetes и контейнеризированные приложения. Расширенные возможности мультиаренды обеспечивают гибкость, необходимую для управления несколькими проектами, сохраняя при этом строгие протоколы безопасности и изоляции.
Инженеры могут легко использовать возможности самообслуживания платформы для быстрого развертывания ресурсов, следуя стандартам управления, установленным облачными администраторами. Такой подход не только повышает продуктивность, но и ускоряет вывод новых приложений на рынок, соответствуя требованиям современных высокоскоростных сред разработки.
Трансформация основной ИТ-инфраструктуры
В Cloud Foundation 9 компания VMware предлагает не только унифицированный опыт, но и возможность непрерывного внедрения инноваций в существующую платформу, представляя прорывные новые функции. Однако, что изменилось в VCF 9, так это инновации как на уровне платформы, так и на уровне отдельных технологий.
Начнем с усовершенствований платформы в целом:
Улучшенный импорт VCF
Интегрирует VMware NSX и различные топологии vSAN непосредственно в среды VCF.
Сокращает время простоя при миграции, обеспечивая бесшовную интеграцию и защиту существующих настроек.
Суверенная мультиаренда VCF
Обеспечивает безопасные, изолированные многопользовательские среды в общей инфраструктуре. Предоставляет индивидуальное управление политиками и ресурсами, увеличивая операционную гибкость.
Операции и безопасность на уровне всех инфраструктур
Централизованное управление всеми развертываниями VCF, улучшая видимость и контроль. Единые конфигурации безопасности по всем активам снижают уязвимости и повышают соответствие требованиям.
Улучшения вычислительных возможностей в VCF9
Начнем с вычислительного стека, где гипервизор находится в центре VCF. Давайте рассмотрим новый набор функций, представленных в VCF 9, которые разработаны для поддержки требований инфраструктуры:
Расширенное распределение памяти с использованием NVMe - эта функция оптимизирует управление памятью, выгружая холодные данные на хранилище NVMe, при этом горячие данные остаются в DRAM. Это приводит к увеличению консолидации серверов на 40%, что позволяет компаниям запускать больше рабочих нагрузок на меньшем количестве серверов.
Конфиденциальные вычисления с TDX - обеспечивает улучшенную безопасность за счет изоляции и шифрования рабочих нагрузок, гарантируя целостность данных и конфиденциальность на уровне гипервизора.
Улучшения службы Kubernetes в vSphere - VCF будет включать готовую поддержку контейнеров Windows, прямое сетевое подключение через VPC и поддержку OVF на нативном уровне, что увеличивает гибкость и масштабируемость контейнеризованных приложений.
Предоставление возможностей хранения с помощью vSAN в VCF 9
Теперь перейдем к стеку хранения данных. vSAN интегрирован в VCF уже много лет и стал основой для развертывания частного облака. Что же будет новым и примечательным в VCF9 в отношении хранения данных?
Нативная защита данных vSAN-to-vSAN с использованием глубоких снапшотов (Deep Snapshots) - обеспечивает практически мгновенное восстановление данных с RPO в 1 минуту, предоставляя надежное решение для восстановления после катастроф и повышения устойчивости данных.
Интегрированная глобальная дедупликация vSAN - снижает затраты на хранение на 46% за терабайт по сравнению с традиционными решениями благодаря эффективной дедупликации данных между кластерами.
Расширенное восстановление vSAN ESA для распределенных сайтов - обеспечивает непрерывность бизнеса, поддерживая операции и доступность данных даже при сбоях на двух сайтах, поддерживая критически важные приложения с использованием архитектуры распределенного кластера.
VCF9 и мощь интегрированных сетей
И наконец, давайте поговорим о сетях. Наличие сетевой инфраструктуры, охватывающей все ваше частное облако, обеспечивающей производительность и соответствие требованиям подключения ваших рабочих нагрузок, имеет ключевое значение. Именно здесь NSX занимает свое место в истории VCF9. Давайте рассмотрим некоторые инновации:
Нативные VPC в vCenter и автоматизация VCF - упрощает создание и управление безопасными, изолированными сетями, снижая сложность и уменьшая время, необходимое для настройки виртуальных сетей.
Высокопроизводительная коммутация сети с NSX Enhanced Data Path - обеспечивает до трехкратного увеличения производительности коммутации, удовлетворяя потребности современных приложений, требующих высокой интенсивности передачи данных, и снижая задержку сети.
Легкий переход от VLAN к VPC - упрощает миграцию от традиционных сетей на основе VLAN к VPC и управление сетью, улучшая безопасность.
Заключение
Предстоящий выпуск VMware Cloud Foundation 9 представляет собой важное усовершенствование в инфраструктуре частного облака, предлагая интегрированные, нативные функции для вычислений, хранения данных и сетей. Это ключевой релиз для любой организации, стремящейся повысить безопасность, оптимизировать производительность и упростить операции в своей ИТ-среде.
Однако, в то время как мы с нетерпением ожидаем инноваций в VCF 9, VMware Cloud Foundation 5.2 уже сегодня делает значительные шаги вперед. Обладая мощными возможностями для управления современной инфраструктурой и модернизации частного облака, VCF 5.2 предлагает мощную платформу, на которой компании могут начать улучшать свои облачные среды уже сейчас.
Для предприятий, стремящихся оставаться конкурентоспособными и безопасными, сейчас самое подходящее время изучить, что может предложить VMware Cloud Foundation, как сегодня, так и в будущем.
Недавно вышла версия VMware Data Services Manager (DSM) v2.1.1 (о версии 2.1 мы рассказывали вот тут). В связи с этим релизом Кормак Хоган решил создать несколько коротких видеороликов, чтобы подчеркнуть некоторые улучшения, которые были внесены в продукт. Напомним, что VMware Data Services Manager (DSM) дает разработчикам средства самообслуживания, которые позволяют регулировать потребление ресурсов, обеспечить комплаенс и соответствие политикам резервного копирования компании, а также дает другие полезные инструменты.
В видео ниже демонстрируется, как начать работу с DSM v2.1.1. В нем показано, как загрузить продукт с портала поддержки, а также рассказывается об использовании плагинов клиента vSphere для развертывания DSM в вашей онпремизной инфраструктуре vSphere.
В ролике показано, как создать свою первую инфраструктурную политику для защиты ресурсов vSphere при развертывании баз данных и сервисов данных. Видео также рассказывает, как завершить настройку DSM, войдя в интерфейс и добавив объектное хранилище для резервного копирования и журналов виртуального модуля (Virtual appliance) провайдера, а также для резервных копий вашей базы данных. После завершения настроек вы будете готовы к включению и развертыванию БД.
В VMware Cloud Foundation (VCF) версии 5.2 появилась новая консоль, которая добавляет диагностические возможности в Operations VMware Cloud Foundation (VMware Aria Operations). VMware Cloud Foundation Operations включен в VCF и VMware vSphere Foundation.
Новые функции включают "Общие выводы" и "Рекомендации по безопасности". Кроме того, такие разделы, как "Серверы vCenter", "Хосты ESXi", "Развертывание рабочих нагрузок" и "Кластеры vSAN", которые ранее были доступны в VMware Cloud Foundation Operations, теперь включены для улучшенной видимости. Также улучшена интеграция с VMware Aria Operations for Logs, что предоставляет больше информации о миграциях vMotion и снапшотах. Чтобы включить эту функцию, необходимо подключить Operations к Operations for Logs и хотя бы одному vCenter. При добавлении дополнительных компонентов VMware vSphere Foundation и VCF станут доступны дополнительные наборы данных. Давайте рассмотрим каждый раздел более подробно.
Общие выводы
В новой версии VMware Cloud Foundation Operations объединены диагностические возможности (из Skyline Health Diagnostics, Skyline Advisor и VMware Aria Operations for Logs) в единый интерфейс, представленный в новой консоли. С помощью Skyline можно применять рекомендации по безопасности и эксплуатации на основе версий. Теперь VMware Cloud Foundation Operations и VMware Aria Operations for Logs привязаны к одним и тем же конечным эндпоинтам, что способствует появлению новых диагностических выводов в консоли, уменьшая необходимость в развертывании дополнительного программного обеспечения (сокращает необходимость в Skyline Advisor Collector и виртуальной машине Skyline Health Diagnostics). Эта бесшовная интеграция уменьшает дублирование усилий, о которых упоминалось ранее, и упрощает развертывание и управление средой. В результате получается системный подход к представлению диагностических выводов клиентам.
Вот некоторые распространенные задачи:
Просмотр всех файндингов
Определение общего количества ресурсов
Категоризация выводов по критичности (критические, срочные и предупреждения)
Классификация по типу:
Рекомендации по безопасности
Доступность
Проверки перед обновлением
Диагностика эксплуатации
Производительность
Уточнение их представления с помощью фильтров на основе:
Инвентарь VCF
Компоненты VCF
Тип файндинга
Серьезность
Возможности:
vMotions
Снапшоты
Развертывание рабочих нагрузок
Домены рабочих нагрузок
DRS
HA
Для доступа к диагностической консоли выберите "Diagnostics" в левой панели навигации. На странице Home -> Overview найдите ссылки на "Appliances Health & Management".
Рисунок 1. Дэшборд главной страницы.
Рисунок 2. Дэшборд диагностики из меню слева.
В основном дэшборде «Overall Findings» вы можете быстро просмотреть все файндинги. Вы можете уточнить их количество, выбрав компоненты в левой панели. Кроме того, вы можете искать конкретные файндинги или использовать подстановочные знаки в строке поиска, расположенной выше списка файндингов.
Рисунок 3. Опции фильтрации и поиска на панели «Diagnostic Findings».
Вы можете углубиться в просмотр конкретных деталей, выбрав отдельный файндинг, например, Last Observed, Affected Objects и Recommendations.
Рисунок 4. Просмотр Last Objerved и Affected Objects.
На вкладке «Affected Objects» вы можете найти имя объекта, время его первого наблюдения (Occurrence Time) и время последней проверки (Check Time). Окружение будет сканироваться каждые четыре часа, и детали на этой вкладке будут обновляться соответственно. Не забудьте учитывать следующую информацию:
Рисунок 5. Просмотр деталей «Affected Objects».
В разделе «Recommendations» вы можете найти версию продукта, в которой проблема была решена, а также статью базы знаний (KB), в которой представлены детали о проблеме, исправлении и воркэраунде.
Рисунок 6. Просмотр рекомендаций по исправленным версиям и статьям базы знаний (KB).
Вот некоторые распространенные сценарии использования:
Просмотр VMSA и CVE для определения возможных проблем и обновлений для определенного набора серверов.
Помощь в планировании обновлений vCenter и ESXi для решения нескольких файндингов одновременно.
Разделение списка файндингов по регионам, чтобы распределить работу среди сотрудников, работающих в разных регионах.
Управление сертификатами
Все сертификаты в среде будут отображены здесь. Эти сертификаты существуют во всех приложениях VMware для обеспечения идентификации приложений (с целью уменьшения риска атак типа «man in the middle»). Поскольку каждое приложение может иметь до трех сертификатов, управление сертификатами занимает много времени и является сложным процессом. С учетом даты истечения срока действия и внешнего центра сертификации, управление графиком обновления и импорта сертификатов может вызывать проблемы.
Когда вы настраиваете консоль диагностики, то заполняется и панель управления сертификатами. Вы можете легко увидеть все сертификаты для конкретного сервера, включая информацию о том, являются ли они самоподписанными или сертификатами CA, а также активны ли они. Для активных сертификатов пользователи могут увидеть оставшееся время до истечения срока действия, что помогает начать процесс обновления сертификатов до их истечения, чтобы предотвратить возможные перебои в работе.
Рисунок 7. Обзор дэшборда управления сертификатами.
Вот некоторые распространенные сценарии использования:
Проверка наличия «неактивных» сертификатов и их немедленное исправление.
Просмотр даты истечения срока действия и немедленное исправление самоподписанных сертификатов.
Превентивное предотвращение истечения срока действия сертификатов.
vCenter
В дэшборде диагностики vCenter вы можете легко просмотреть все vCenter, подключенные к VCF Operations. Здесь объединяются все данные из vCenter, а также данные из VCF Operations. Вы можете быстро проверить операционный статус каждого vCenter. Если какой-либо vCenter не работает, вы можете определить количество затронутых хостов ESXi и виртуальных машин. Кроме того, вы можете увидеть все службы, запущенные на конкретном vCenter. В течение нескольких секунд можно определить, какие службы не работают, устранить проблемы и вернуть их в рабочее состояние. Этот процесс занял бы 30 минут или больше, если бы использовались традиционные методы, такие как проверка vCenter через консоль сервера и файлы журналов. При необходимости можно выбрать отдельные vCenter для более детального исследования.
Рисунок 8. Дэшборд vCenter.
Вот некоторые распространенные сценарии использования:
Проверка доступности любого vCenter и определение затронутых серверов и виртуальных машин.
Просмотр служб на каждом vCenter, чтобы убедиться, что все они работают нормально.
Хосты ESXi
Дэшборд ESXi предоставляет важную диагностическую информацию о хостах ESXi. Во-первых, вы можете проверить наличие «неотвечающих ESXi» серверов, так как это вопросы высокого приоритета. Далее, вы можете проверить, находятся ли какие-либо ESXi серверы в режиме обслуживания и определить, должны ли они оставаться в этом режиме или выйти из него. Также важно обратить внимание на серверы ESXi, которые были «отключены» или «не отвечают» в течение длительного времени. При выборе каждого ESXi сервера вы можете получить доступ к настройкам «родительского кластера», что может предоставить ценные сведения о возможных проблемах. В течение нескольких секунд можно выявить проблемы и инициировать необходимые действия по их устранению.
Рисунок 9. Дэшборд ESXi.
Вот некоторые распространенные сценарии использования:
Выявление всех «не отвечающих» серверов ESXi и их восстановление до нормального состояния.
Проверка ESXi режиме обслуживания для уверенности в том, что они действительно должны там находиться. Вывод из режима обслуживания как можно скорее для оптимального использования ресурсов.
Определение «Родительского кластера» конкретного ESXi и проверка правильности всех настроек.
Развертывание рабочих нагрузок
На панели управления развертыванием рабочих нагрузок вы можете просмотреть общие задачи по управлению нагрузкой, такие как «Создать новую виртуальную машину», «Развернуть OVF» и «Клонировать виртуальную машину». Вы можете быстро выявить любые сбои. При просмотре деталей пользователи могут увидеть информацию, такую как «Время запроса», «Имя виртуальной машины», «Инициатор», «vCenter» и «Кластер». С этой информацией вы можете исследовать окружение на наличие потенциальных проблем, выполнить необходимые исправления и уведомить инициаторов о необходимости повторного выполнения их задач.
Рисунок 10. Дэшборд развертывания рабочих нагрузок.
Вот некоторые распространенные сценарии использования:
Определение всех диагностических файндингов, связанных с развертыванием рабочих нагрузок.
Проверка любых сбоев для выявления основной причины проблемы.
Просмотр «инициаторов», чтобы убедиться, что все пользователи правильно назначены.
Миграции vMotion
Технология vMotion существует уже достаточно давно. Вы можете наблюдать за активностью vMotion в списке «recent tasks» в консоли vCenter. Однако ранее не было возможности видеть все события vMotion из одного представления. Теперь у вас есть такая возможность. Вы можете выбрать каждый vCenter, чтобы просмотреть все случаи vMotion, определяя как сбои, так и успешные события. В случае сбоя вы можете просмотреть такие детали, как имя виртуальной машины, источник, назначение и время, что поможет выявить и устранить проблему, предотвращая аналогичные сбои в будущем. Для тех, кто использует HCX (который использует vMotion), также фиксируются все активности HCX vMotion.
Рисунок 11. Дэшборд vMotion.
Вот некоторые распространенные сценарии использования:
Определение всех диагностических файндингов, связанных с vMotion.
Просмотр всех локаций, а также каждого vCenter на основе прошлых проблем.
Проверка исходного и целевого хостов для выявления проблем.
Снапшоты
В диагностической консоли вы можете просмотреть все снапшоты в окружении. Вы сможете определить наиболее проблемные виртуальные машины с проблемами снапшотов, особенно те, которые требуют консолидации. Еще один важный аспект — оценка общего количества снимков для семи наиболее важных виртуальных машин. У вас есть возможность фильтровать успешные и неудачные снимки. Для каждой проблемы, связанной со снимками, вы можете просмотреть такие детали, как виртуальные машины, vCenter, хранилище данных и временная метка. Это должно предоставить достаточно информации, чтобы определить, является ли проблема специфичной для конкретной виртуальной машины или это системная проблема, связанная с vCenter, ESXi или хранилищем данных.
Рисунок 12. Дэшборд снапшотов.
Вот некоторые распространенные сценарии использования:
Определение всех диагностических файндингов, связанных со снапшотами.
Просмотр любых сбоев.
Сопоставление любого сбоя с проблемой ESXi, графиком резервного копирования или другими сбоями (сеть, хранилище и т.д.).
Кластеры vSAN
Раздел «vSAN Health» в диагностической консоли предоставляет обзор состояния инфраструктуры vSAN. Вы можете быстро отфильтровать количество предупреждений «Красного», «Оранжевого» и «Желтого» уровня. При выборе каждого кластера появятся детали о свойствах выбранного кластера, которые помогут убедиться, что все необходимые настройки корректны. Ниже вы можете просмотреть детали каждого предупреждения, что поможет правильно расставить приоритеты и устранить проблемы для обеспечения наилучшей производительности и стабильности кластера vSAN.
Рисунок 13. Панель управления здоровьем vSAN.
Вот некоторые распространенные сценарии использования:
Просмотр всех предупреждений «Красного», «Оранжевого» и «Желтого» уровня.
Проверка всех свойств выбранного кластера на правильность настроек.
Прохождение по всем выводам по отдельности для планирования обновления с целью решения проблем.
После изучения всех функций в диагностической консоли (файндинги, сертификаты, vCenter, ESXi, развертывание рабочих нагрузок, vMotion, снапшоты и кластеры vSAN) вы можете оценить значимость новых дэшбордов. Некоторые из них представляют собой недавно добавленные функции из других продуктов, а другие — это детали существующих панелей, объединенные в этой консоли. Цель заключается в предоставлении ценных сведений с минимальными усилиями по развертыванию и настройке. Это позволит использовать существующие экземпляры Aria Operations и Operations for Logs, что в конечном итоге сэкономит время клиентов на решение проблем и сократит время простоя и обслуживания.
Компания VMware выпустила интересный документ "Troubleshooting vSAN Performance", в котором рассматриваются вопросы решения проблем в области производительности отказоустойчивых хранилищ VMware vSAN.
Статья на VMware Core разделена на несколько ключевых разделов:
1. Определение проблемы: начальный этап, включающий идентификацию проблемы и её масштаба. 2. Обзор конфигурации: анализ текущей конфигурации vSAN, включая параметры хранилища, сеть и оборудование. 3. Анализ рабочих нагрузок: изучение типов нагрузок, которые могут влиять на производительность. 4. Метрики и инструменты: описание ключевых метрик и инструментов для мониторинга и диагностики, таких как vSAN Observer и vRealize Operations. 5. Рекомендации по оптимизации: практические советы по настройке и оптимизации для повышения производительности, включая изменения в программных и аппаратных компонентах.
Каждый из этих этапов направлен на систематическое выявление и устранение узких мест в производительности vSAN. Статья предлагает практические примеры и сценарии для понимания и решения типичных проблем.
Стратегии защиты данных часто включают снапшоты в той или иной форме. Они могут быть важной частью комплексной стратегии защиты данных 3-2-1, а также дополнять официальные практики защиты данных, делая операции восстановления более удобными. Однако снапшоты могут создавать технические проблемы и ограничения, которые влияют на их использование в производственных средах.
С выпуском VMware vSAN 8 U3 в составе Cloud Foundation 5.2, компания VMware представила защиту данных vSAN. Основанная на революционной архитектуре vSAN Express Storage Architecture (ESA), она представляет собой значительное изменение в способности клиентов защищать, восстанавливать и клонировать виртуальные машины с использованием знакомого им программного обеспечения.
Новые возможности с улучшенными снапшотами
Основа защиты данных vSAN заключается в механизме создания снапшотов, представленного в составе vSAN ESA. Дизайн vSAN ESA позволил инженерам разработать совершенно новый механизм создания снапшотов с нуля, отказавшись от старого подхода на основе redo-log, который использовался в оригинальной архитектуре хранения данных. Новый механизм создания снапшотов в vSAN ESA основан на запатентованной лог-структурированной файловой системе (LFS) и высокоэффективных структурах метаданных.
Различные формы лог-структурированных файловых систем широко распространены сегодня, но VMware имеет уникальную историю с этой технологией, так как Мендель Розенблюм, соучредитель VMware, первым внедрил лог-структурированную файловую систему еще в 1992 году. Файловая система LFS в vSAN новаторская по нескольким направлениям. Она реализована на основе объектов, что позволяет добиться более тонкого уровня управления по сравнению с монолитными подходами. Она также распределенная, что обеспечивает масштабируемость и гибкость, обычно ассоциируемые с распределенными системами.
Механизм создания снапшотов в vSAN ESA позволяет хранить снапшоты практически без потери производительности. Преимущества аналогичны снапшотам на основе массивов (storage-based snapshots), которые часто хвалят за их эффективность и производительность. Но снапшоты vSAN ESA имеют некоторые отличительные преимущества перед снапшотами на основе массивов, которые существенно влияют на их полезность в производственной среде.
Проблемы снапшотов на основе массивов
Наиболее распространенный способ представления ресурсов емкости в хранилищах — через тома LUN. В сочетании с кластерной файловой системой, такой как VMFS, это позволяет разместить десятки или сотни различных ВМ и их файлов на одном LUN для использования хостами vSphere, подключенными к хранилищу данных. Хотя это работало достаточно хорошо в течение многих лет, но у этого подхода есть некоторые присущие проблемы.
1. Единица управления. Хотя вас могут интересовать несколько конкретных ВМ в LUN, массив рассматривает данные в LUN целиком. Снапшот на основе массива захватывает все измененные данные в LUN, включая ВМ, которые вы, возможно, не хотели бы захватывать. Это может увеличить потребление емкости и усложнить восстановление.
2. Создание и координация снапшотов. Неестественная единица управления, предоставляемая LUN, — это лишь часть проблемы при создании снапшотов. Механизмы создания снапшотов на основе массива не имеют осведомленности о самой ВМ или о том, когда операции ввода-вывода инициированы ВМ. Дополнительные операции могут потребоваться для захвата снимка всего LUN, чтобы ввод-вывод сохранялся в согласованном состоянии. Это означает, что в зависимости от обстоятельств гипервизор может приостанавливать каждую ВМ, использующую этот LUN, чтобы массив мог захватить ВМ в согласованном состоянии. Это требует времени и точной координации.
3. Восстановление снапшотов. Восстановление ВМ до предыдущего состояния с использованием снапшота на основе массива обычно включает несколько шагов для временного представления LUN хостам без вмешательства в существующие ВМ. Текущую ВМ нужно удалить, а старую ВМ скопировать в новое место и перерегистрировать в vCenter Server, после чего отсоединить временный LUN и выполнить другие операции очистки. Это процесс, который может быть трудоемким и подверженным ошибкам.
Привязка к LUN и отсутствие осведомленности об операциях ввода-вывода ВМ часто приводят к увеличению сложности операций. vSAN решает задачу создания снапшотов более эффективным способом.
Более эффективный подход к созданию снимков данных
Снимки в vSAN ESA обладают возможностями, аналогичными снапшотам на основе массивов, но без многих проблем. Как отмечено в посте vSAN Objects and Components Revisited, vSAN хранит данные, аналогичные объектному хранилищу. vSAN использует набор отдельных объектов, представляющих аспекты ВМ, такие как виртуальные диски (VMDK). Эта меньшая гранулярность данных в vSAN обеспечивает лучшую доступность, масштабируемость и управление. Но эта модель имеет значительное преимущество при создании снапшотов ВМ.
Единица управления: снапшоты ESA создаются для каждой ВМ. Пользователи сфокусированы именно на машинах, поэтому имеет смысл делать это таким образом. При создании снимков ESA изменения, отслеживаемые после создания снапшота, касаются только ВМ с этим снапшотом.
Создание и координация снапшотов: поскольку vSAN является частью гипервизора, он полностью видит и контролирует путь данных ВМ. Это позволяет механизму создания снапшотов создавать их, гарантируя, что данные фиксируются в состоянии согласованности после сбоя без остановки ВМ. Это быстро и совершенно прозрачно для пользователя.
Восстановление снапшотов: независимо от того, восстанавливаете ли вы существующую ВМ на предыдущий момент времени или восстанавливаете удаленную ВМ, процесс восстановления прост и интуитивно понятен. Восстанавливайте ВМ легко прямо в интерфейсе vSphere в vCenter Server.
Снапшоты, выполненные на уровне ВМ, являются более значимой единицей управления для клиентов. Этот подход не только более интуитивен, но и намного эффективнее, так как делает снапшоты только тех ВМ, которые вам нужны, а не всё на томе LUN.
Лучший подход к защите данных
Однако быстрый и масштабируемый механизм создания снапшотов был недостаточным. Клиенты хотели использовать снапшоты для восстановления и манипуляции данными, а также планировать задачи и сохранять снапшоты автоматически. Они хотели сделать это легко и интегрировать со средствами vCenter Server. Это то, что VMware реализовала в vSAN Data Protection.
Защита данных vSAN предоставляет клиентам то, что они всегда хотели
Легкий в использовании, эффективный и интегрированный способ защиты данных, встроенный в уже известное программное обеспечение. VMware не только достигли этого, но и благодаря архитектуре внедрили инновации, делающие его удобным и гибким.
Экстремально быстрые операции
Cнапшоты на уровне ВМ делают операции простыми и быстрыми. vSAN контролирует ввод-вывод по всей цепочке, минимизируя задержки при создании и восстановлении снимков.
Масштабируемость снапшотов
vSAN Data Protection поддерживает до 200 снапшотов на ВМ, преодолевая ограничение в 32 снапшота при использовании традиционных методов в vCenter Server и API на основе VADP.
Динамическая группировка
Основой использования vSAN Data Protection являются «группы защиты» (protection groups). Это логические контейнеры, в которых можно группировать несколько ВМ для легкого и повторяемого создания и управления снапшотами. В пределах группы защиты можно определить политику, например, частоту защиты и расписание хранения. ВМ могут быть назначены статически или динамически с использованием символов подстановки «*» и «?». Например, назначение членства с помощью «SQL-*» позволяет защитить все ВМ с именем, включающим «SQL-».
Опциональная неизменяемость данных
Снапшоты могут быть сделаны неизменяемыми, что означает, что снапшот нельзя изменить или удалить. Эта опция, доступная в настройках группы защиты, обеспечивает базовую защиту от злонамеренных действий и интегрируется с VMware Live Cyber Recovery (VLCR), комплексным решением для защиты от вымогателей.
Защита системы
Снимки могут увеличивать потребление емкости, если скорость изменения данных и частота создания снапшотов высоки. Для защиты от непреднамеренных проблем с потреблением данных vSAN Data Protection приостанавливает создание снапшотов, если достигнуто 70% емкости кластера. Также автоматически истекают снапшоты пытающиеся превысить лимит в 200 снимков на ВМ.
Практическое использование vSAN Data Protection
Хотя технология впечатляет, важен результат. Легкая защита должна сочетаться с легким оперативным восстановлением для использования в реальных сценариях. Вот несколько примеров использования vSAN Data Protection:
1. Возврат существующих ВМ к предыдущему состоянию. Быстрое восстановление ВМ, которые могли быть случайно неправильно настроены, неудачно обновлены или подверглись подозрительной деятельности. 2. Восстановление удаленных ВМ. Легко восстановите ВМ, которые больше не зарегистрированы в vCenter Server, что помогает защититься от случайного или злонамеренного удаления ВМ. 3. Клонирование ВМ. Быстрое создание клона ВМ из снимка, что может быть простым и эффективным способом иметь несколько копий данных. 4. Защита от вымогателей. vSAN Data Protection можно использовать с VMware Live Cyber Recovery (VLCR), чтобы легко создать комплексное решение для защиты и восстановления от вымогателей.
На данный момент vSAN Data Protection ограничивается предоставлением локальной защиты ВМ. Но это может быть идеальным дополнением к существующим и более комплексным стратегиям резервного копирования 3-2-1. Для получения дополнительной информации и ответов на часто задаваемые вопросы, ознакомьтесь с vSAN Data Protection FAQs.
Заключение
vSAN Data Protection представляет собой лучший способ защиты и восстановления виртуальных машин. Она использует возможности vSAN ESA, чтобы предоставить преимущества, которые трудно достичь с внешними подходами на основе массивов. И, что самое главное, vSAN Data Protection уже доступна в вашей лицензии VCF.
Все они стали доступны одновременно с релизом платформы VMware Cloud Foundation 5.2. В состав этого комплексного решения также вошло и средство VMware HCX 4.10, предназначенное для миграции с различных онпремизных инфраструктур (как на платформе vSphere, так и Hyper-V или KVM) в облако на базе VMware Cloud и между облаками.
VMware HCX 4.10.0 является минорным релизом, который предоставляет новые функции, улучшения совместимости и удобства использования, а также обновления безопасности и исправления. Важные изменения касаются лицензионного фреймворка, улучшения управления трафиком, миграции, интерконнекта и поддержки различных систем.
Давайте посмотрим на новые возможности VMware HCX 4.10:
Важная информация
В версии HCX 4.9.0 VMware ввела единый лицензионный фреймворк для активации продуктов VMware Cloud Foundation и VMware vSphere Foundation. При обновлении до HCX 4.10 с версии ниже HCX 4.9.0, ознакомьтесь с изменениями в лицензировании и активации, описанными в заметках к релизу HCX 4.9.0. Всем существующим клиентам HCX, не использующим hyperscaler-облака, рекомендуется обновиться как можно скорее для обеспечения наивысшего уровня поддержки и портируемости продуктов VMware.
Улучшения управления трафиком
Настраиваемое шифрование транспорта для миграции и трафика расширения сети: по умолчанию трафик миграции и расширения сети HCX зашифрован. В этой версии введена опция Service Mesh для активации или деактивации шифрования для каждого из этих сервисов. Отключение шифрования доступно для безопасных сетей Uplink.
Generic Receive Offload (GRO): для входящего трафика расширения сети можно настроить GRO в настройках Traffic Engineering для Service Mesh, что улучшает производительность приложений.
Улучшения миграции
Параметризация сайтов с не-vSphere для OS Assisted Migration (OSAM): теперь можно связывать сайты не на базе vSphere с HCX Connector или HCX Cloud Manager для миграции рабочих нагрузок с помощью OSAM, упрощая процесс миграции.
HCX Assisted vMotion: новый тип миграции, работающий в сочетании с native cross-vCenter vMotion для оркестрации миграций между хостами VMware ESXi.
Поддержка новых гостевых ОС для OSAM: Поддерживаются дополнительные операционные системы, такие как RHEL 8.9 и выше, Ubuntu 20.04 и 22.04, а также Rocky Linux 8.4 и выше.
Массовая миграция (per-VM EVC): включает опцию деактивации Enhanced vMotion Compatibility для отдельных виртуальных машин.
Миграция тегов vCenter: введена репликация тегов vCenter с исходного сайта на целевой сайт для более удобной настройки.
Улучшения интерконнекта
HCX Intrasite Control Network: Новый тип сети для связи между HCX Interconnect и WAN Optimization, что разгружает задачи от сети Management Network.
Конфигурация Compute Profile: HCX проверяет, что все профили сети охватывают все кластеры, чтобы предотвратить ошибки развертывания.
Улучшения расширения сети
Разрешение пересекающихся подсетей: появилась опция разрешения пересекающихся подсетей для Network Extension, что полезно в случаях, когда сети имеют разные vLAN.
Улучшения совместимости
VMware Cloud Foundation 5.2: HCX 4.10 совместим с VMware Cloud Foundation 5.2, улучшая масштабируемость и отказоустойчивость.
VMware vSphere/vSAN 8.0 Update 3: поддержка миграций для виртуальных машин, использующих HW версию 21.
VMware NSX 4.2: поддержка всех сетевых и миграционных функций в средах vSphere с NSX 4.2.
VMware vSAN Max: возможность использования хранилищ vSAN Max в качестве целевых для мигрируемых рабочих нагрузок.
Улучшения пользовательского интерфейса
Интерфейс Site Pairs: Теперь связанные сайты отображаются как отдельные карточки.
Интерфейс Interconnect: локальные менеджеры Interconnect теперь показывают настройки Network Profile, Compute Profile и Service Mesh в одном месте.
Конфигурация Service Mesh: включает отдельные мастера для создания Service Mesh для сайтов на основе vSphere и не-vSphere.
Эти улучшения делают VMware HCX 4.10.0 более мощным инструментом для миграции и управления сетями, обеспечивая повышение производительности, безопасности и удобства использования.
Подробнее обо всем этом вы можете почитать в Release Notes.
Недавно мы писали о новых возможностях продукта VMware NSX 4.2, который стал доступен одновременно с релизом платформы VMware Cloud Foundation 5.2. В состав этого комплексного решения также вошло и средство VMware Aria Operations 8.18 для управления и мониторинга виртуального датацентра. Напомним также, что о версии Aria Operations 8.16 мы писали вот тут.
Удаленные коллекторы
VMware Aria Operations 8.14 был последним релизом, поддерживающим удаленные коллекторы. В версиях 8.16 и позднее обновления невозможны при наличии удаленных коллекторов. Для обновления необходимо заменить все удаленные коллекторы на облачные прокси. Это изменение улучшит сбор данных и упростит управление.
Устаревание XML в REST API
В следующем крупном релизе VMware Aria Operations поддержка XML в новых API и новых функциях существующих API будет прекращена. Для обмена данными рекомендуется использовать JSON, хотя текущие API продолжат поддерживать XML.
Поддержка облачных платформ и новых интеграций
Поддержка интеграций с облачными платформами Amazon Web Services, Microsoft Azure, Oracle Cloud VMware Solution и Google Cloud Platform будет доступна только через Marketplace. Важно обновить адаптер Google Cloud Platform до версии 8.18 сразу после обновления кластера, чтобы избежать потери данных.
Улучшенная навигация и управление
Введено новое меню навигации, ориентированное на выполнение задач, и средства для управления стеком VMware Cloud Foundation, включая обновление сертификатов, контроль конфигураций и диагностику. На вкладке Overview на главной странице представлены возможности управления и мониторинга VMware Cloud Foundation.
Диагностика и мониторинг
Теперь можно получать информацию о известных проблемах, влияющих на программное обеспечение VMware, и следить за состоянием ключевых случаев использования VMware Cloud Foundation, таких как vMotion, Snapshots и Workload Provisioning. Введены новые функции для контроля и устранения отклонений конфигураций vCenter.
Единый вход и управление лицензиями
Поддержка единого входа (SSO) для VMware vSphere Foundation с возможностью импорта пользователей и групп из провайдера SSO. Управление лицензиями VMware Cloud Foundation и VMware vSphere Foundation теперь доступно в VMware Aria Operations.
Управление сертификатами
Появилось централизованное управление сертификатами для всех компонентов VMware Cloud Foundation. Также есть и возможность мониторинга и получения информации о сертификатах инфраструктуры VMware Cloud Foundation.
Улучшение пользовательского опыта и отчетности
Обновленный опыт работы с инвентарем и виджетами, поддержка просмотра объектов с предками и потомками, возможность фильтрации по возрасту объектов и определениям предупреждений. Возможность добавления до пяти панелей инструментов на главную страницу и их упорядочивания.
Снижение шума предупреждений и улучшение панели инструментов
Введение 20-секундной пиковой метрики, что позволяет получить более четкую видимость данных и уменьшить шум предупреждений. Обновленные панели инструментов, такие как панель изменений VM и панель производительности кластеров, обеспечивают лучшую видимость и взаимодействие.
Управление емкостью и стоимостью
Возможность переопределения метрик для расчета емкости и получения рекомендаций по оптимизации ресурсов. Управление затратами на лицензии VMware по ядрам, а также доступность метрик затрат для проектов и развертываний VMware Aria Automation.
Миграция Telegraf и усиление безопасности
Поддержка сохранения конфигурации плагинов Telegraf при переустановке и усиление безопасности за счет ограничения входящих сетевых подключений и предотвращения несанкционированного доступа.
Улучшения для vSAN и отчеты о соответствии
Поддержка кластера vSAN Max и улучшения виджетов для отображения информации о предках и потомках объектов. Обновления пакетов соответствия для CIS и DISA, поддержка новых версий ESXI и vSphere.
Эти новые возможности и улучшения делают VMware Aria Operations 8.18 более мощным и удобным инструментом для управления виртуальной инфраструктурой, повышая эффективность и безопасность работы с облачными и локальными ресурсами.
Подробнее обо всем этом вы можете почитать в Release Notes.
Коллеги выпустили третий эпизод серии видео о VMware Cloud Foundation 5.2 (предыдущие эпизоды серии вы можете найти тут). В этом выпуске специалисты компании обсудили основные моменты релиза VCF 5.2, который стал доступен для загрузки с 24 июля 2024 года. Тут уже не показывают процесс развертывания, но подробно рассматривается заполнение таблицы Excel, необходимой для настройки VCF. Вы узнаете, как конвертировать эту таблицу в формат JSON с помощью командной строки.
Одним из важных нововведений версии VCF 5.2 является возможность указания единого пароля для всех компонентов при быстрой настройке. Вы также сможете задать уникальные пароли для каждого компонента, если это требуется для обеспечения безопасности. В видео обсуждается настройка сетей, включая сети управления, сети ВМ, сети vMotion и vSAN, а также распределенные виртуальные коммутаторы и профили сетевых карт. Особое внимание уделено конфигурации сетевых параметров, таких как VLAN, группы портов и MTU.
Вы также узнаете о параметрах развертывания, включая настройки DNS и NTP серверов, лицензии и сайзинг ресурсов. В видео рассмотрены опции архитектуры (консолидированной и стандартной) и параметры безопасности, такие как проверка отпечатков RSA и SSL.
Наконец, будет показано, как загрузить таблицу конфигурации в Cloud Builder и как сгенерировать JSON-файл из таблицы Excel для более тонкой настройки параметров.
Этот эпизод даст вам полное понимание процесса подготовки и настройки VMware Cloud Foundation 5.2, что поможет вам успешно развернуть и управлять вашей виртуальной инфраструктурой. Также коллеги уже начали рассматривать процесс запуска и настройки SDDC Manager:
Вильям Лам написал полезную статью о новой фиче вышедшего недавно обновления фреймворка для управления виртуальной инфраструктурой с помощью сценариев - VMware PowerCLI 13.3.
Параметры загрузки ядра (kernel boot options) в VMware ESXi можно добавить во время загрузки ESXi (нажав SHIFT+O) или обновив файл конфигурации boot.cfg, чтобы повлиять на определенные настройки и/или поведение системы.
Раньше было сложно получить полную картину по всем ESXi хостам, чтобы определить, на каких из них используются пользовательские параметры загрузки, особенно в тех случаях, когда они уже не нужны или, что хуже, если кто-то вручную добавил настройку, которую вы не планировали.
В vSphere 8.0 Update 3 добавлено новое свойство bootCommandLine в vSphere API, которое теперь предоставляет полную информацию обо всех параметрах загрузки, используемых для конкретного ESXi хоста.
На днях был выпущен релиз PowerCLI 13.3, который поддерживает последние API, представленные как в vSphere 8.0 Update 3, так и в VMware Cloud Foundation (VCF) 5.2. Вы можете легко получить доступ к этому новому свойству, выполнив следующую команду в сценарии:
За месяц до VMware Explore 2024 в Лас-Вегасе компания VMware представила новую версию PowerCLI 13.3. В этом выпуске исправлены многочисленные ошибки, добавлены улучшения и новые возможности, такие как командлет для отчета о привилегиях Privilege Report и другие. Давайте разберем все детали этой новой версии PowerCLI. А о возможностях прошлой версии PowerCLI 13.2 вы можете почитать у нас тут.
Улучшения VCF SDDC Manager
В версии 13.3 было добавлено два новых командлета:
Wait-VcfTask — позволяет ожидать завершения асинхронных операций, например задач.
Wait-VcfValidation — позволяет ожидать завершения конкретных операций проверки VCF, например операций проверки доменов.
Улучшения vSphere
Был добавлен новый командлет для записи проверок привилегий, которые происходят для указанных сессий при выполнении указанного блока сценария:
Get-VIPrivilegeReport
Улучшения VSAN
В PowerCLI 13.3 было добавлено два новых командлета для настройки пороговых значений алармов:
New-AlarmTriggerArgument — создает новый триггер действия для указанного аларма.
Get-AlarmTriggerArgumentAttributeName — выводит имена атрибутов аргумента триггера тревоги для события типа "vsan.health.ssd.endurance".
Также было обновлено несколько существующих командлетов:
Get-VsanSpaceUsage — добавлена поддержка нового атрибута "коэффициент эффективности использования пространства" в типе возвращаемых данных.
Set-VsanClusterConfiguration — добавлен новый параметр "vsanmaxenabled" для включения службы vSAN Max.
Get-VsanClusterConfiguration — добавлен новый параметр "vsanmaxenabled" для проверки, включен ли кластер vSAN как vSAN Max.
Улучшения HSX
В PowerCLI 13.3 добавлено два новых командлета для настройки гостевых операционных систем:
New-HCXGuestOSNetworkCustomization - создает объект для настройки сети, который является частью кастомизации гостевой ОС.
New-HCXGuestOSCustomization - создает объект для кастомизации гостевой ОС.
Следующие два командлета обновлены для использования вышеупомянутых новых командлетов в качестве параметров:
New-HCXMigration — для настройки гостевой ОС на уровне миграции.
New-HCXMobilityGroupConfiguration — для настройки гостевой ОС на уровне группы.
Улучшения Image Builder
В PowerCLI 13.3 теперь есть поддержка Python версии 3.12. Наряду с этим добавлена поддержка OpenSSL 3.0. Поддержка OpenSSL 1.1 прекращена из-за завершения срока поддержки, объявленного в сентябре 2023 года.
Обновленные модули SDK
Следующие модули обновлены в PowerCLI 13.3:
Модули vSphere обновлены до vSphere 8.0U3.
Модули NSX обновлены до NSX 4.2.0.0.
Модули SRM и vSphere Replication обновлены до версии 9.0.1.
Модуль VCF обновлен до VMware Cloud Foundation 5.2.
Для получения более подробной информации, пожалуйста, ознакомьтесь с подробным журналом изменений и Release Notes для PowerCLI 13.3.
Наверняка вы слышали о недавнем обновлении программного обеспечения CrowdStrike для Microsoft Windows, которое вызвало беспрецедентный глобальный сбой по всему миру (а может даже вы были непосредственно им затронуты). Несколько дней назад ИТ-администраторы работали круглосуточно, чтобы восстановить работоспособность тысяч, если не десятков тысяч систем Windows.
Текущий рекомендуемый процесс восстановления от CrowdStrike определенно болезненный, так как он требует от пользователей перехода в безопасный режим Windows для удаления проблемного файла. Большинство организаций используют Microsoft Bitlocker, что добавляет дополнительный шаг к уже и так болезненному ручному процессу восстановления, так как теперь необходимо найти ключи восстановления перед тем, как войти в систему и применить исправление.
Вильям Лам написал об этой ситуации. В течение нескольких часов после новостей от CrowdStrike он уже увидел ряд запросов от клиентов и сотрудников на предмет наличия автоматизированных решений или скриптов, которые могли бы помочь в их восстановлении, так как требование к любой организации вручную восстанавливать системы неприемлемо из-за масштабов развертываний в большинстве предприятий. Ознакомившись с шагами по восстановлению и размышляя о том, как платформа vSphere может помочь пользователям автоматизировать то, что обычно является ручной задачей, у него возникло несколько идей, которые могут быть полезны.
Скрипты, предоставленные в этой статье, являются примерами. Пожалуйста, тестируйте и адаптируйте их в соответствии с вашей собственной средой, так как они не были протестированы официально, и их поведение может варьироваться в зависимости от среды. Используйте их на свой страх и риск.
Платформа vSphere обладает одной полезной возможностью, которая до сих пор не всем известна, позволяющей пользователям автоматизировать отправку нажатий клавиш в виртуальную машину (VM), что не требует наличия VMware Tools или даже запущенной гостевой операционной системы.
Чтобы продемонстрировать, как может выглядеть автоматизированное решение для устранения проблемы CrowdStrike, Вильям создал прототип PowerCLI-скрипта под названием crowdstrike-example-prototype-remediation-script.ps1, который зависит от функции Set-VMKeystrokes. В настройке автора работает Windows Server 2019 с включенным Bitlocker, и он "смоделировал" директорию и конфигурационный файл CrowdStrike, которые должны быть удалены в рамках процесса восстановления. Вместо загрузки в безопасный режим, что немного сложнее, автор решил просто загрузиться в установщик Windows Server 2019 и перейти в режим восстановления, что позволило ему применить тот же процесс восстановления.
Ниже представлено видео, демонстрирующее автоматизацию и шаги, происходящие между PowerCLI-скриптом и тем, что происходит в консоли виртуальной машины. Вручную никакие действия не выполнялись:
В зависимости от вашей среды и масштаба, вам может потребоваться настроить различные значения задержек, и это следует делать в тестовой или разработческой среде перед развертыванием поэтапно.
В качестве альтернативы, автор также рекомендует и немного другой подход. Один из клиентов создал кастомный WindowsPE ISO, который содержал скрипт для удаления проблемного файла CrowdStrike, и всё, что им нужно было сделать, это смонтировать ISO, изменить порядок загрузки с жесткого диска на CDROM, после чего ISO автоматически выполнил бы процесс восстановления, вместо использования безопасного режима, что является довольно умным решением.
В любом случае, вот пример фрагмента PowerCLI-кода, который реконфигурирует виртуальную машину (поддерживается, когда ВМ выключена) для монтирования нужного ISO из хранилища vSphere и обновляет порядок загрузки так, чтобы машина автоматически загружалась с ISO, а не с жесткого диска.
$vmName = "CrowdStrike-VM"
$isoPath = "[nfs-datastore-synology] ISO/en_windows_server_version_1903_x64_dvd_58ddff4b.iso"
$primaryDisk = "Hard disk 1"
$vm = Get-VM $vmName
$vmDevices = $vm.ExtensionData.Config.Hardware.Device
$cdromDevice = $vmDevices | where {$_.getType().name -eq "VirtualCdrom"}
$bootDevice = $vmDevices | where {$_.getType().name -eq "VirtualDisk" -and $_.DeviceInfo.Label -eq $primaryDisk}
# Configure Boot Order to boot from ISO and then Hard Disk
$cdromBootDevice = New-Object VMware.Vim.VirtualMachineBootOptionsBootableCdromDevice
$diskBootDevice = New-Object VMware.Vim.VirtualMachineBootOptionsBootableDiskDevice
$diskBootDevice.DeviceKey = $bootDevice.key
$bootOptions = New-Object VMware.Vim.VirtualMachineBootOptions
$bootOptions.bootOrder = @($cdromBootDevice,$diskBootDevice)
# Mount ISO from vSphere Datastore
$cdromBacking = New-Object VMware.Vim.VirtualCdromIsoBackingInfo
$cdromBacking.FileName = $isoPath
$deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec
$deviceChange.operation = "edit"
$deviceChange.device = $cdromDevice
$deviceChange.device.Backing = $cdromBacking
$deviceChange.device.Connectable.StartConnected = $true
$deviceChange.device.Connectable.Connected = $true
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.deviceChange = @($deviceChange)
$spec.bootOptions = $bootOptions
$task = $vm.ExtensionData.ReconfigVM_Task($spec)
$task1 = Get-Task -Id ("Task-$($task.value)")
$task1 | Wait-Task | Out-Null
Чтобы подтвердить, что изменения были успешно применены, вы можете использовать интерфейс vSphere или следующий фрагмент PowerCLI-кода:
Остается только запустить виртуальную машину, а затем, после завершения восстановления, можно отменить операцию, размонтировав ISO и удалив конфигурацию порядка загрузки, чтобы вернуть исходное поведение виртуальной машины.
После неудачного развертывания VCF 5.0 у автора блога vronin.nl остался vSAN Datastore на первом хосте в кластере, что блокировало повторную попытку развертывания.
В этом состоянии vSAN Datastore не может быть удален. Если попытаться его удалить через ESXi Host Client, опция будет неактивна:
Чтобы удалить хранилище данных vSAN и разделы дисков, сначала нужно подключиться по SSH к хосту и получить Sub-Cluster Master UUID кластера:
Далее копируем этот Sub-Cluster Master UUID в следующую команду:
В ESXi Host Client будет показываться, что датастора больше нет:
Для двойной проверки выполняем следующие команды в консоли ESXi:
esxcli vsan cluster list
esxcli vsan storage list
По результатам вывода команд, на хосте не настроены кластеры или хранилища vSAN. После этого повторная попытка развертывания кластера управления VCF будет успешной.
Среди новых возможностей последнего обновления платформы виртуализации VMware vSphere 8 Update 3 появилась интересная новая функция, которая позволяет удалять снапшоты виртуальных машин, которые старше некоторого количества дней, которое задается при выполнении этой операции.
Вы можете объединить эту новую возможность в vSphere 8.0 Update 3 с существующей задачей планирования vSphere (Scheduled Tasks), которая периодически очищает существующие снимки, и администраторы теперь имеют дополнительную возможность для быстрой установки возраста снимка, который нужно удалить, без необходимости создавать или полагаться на пользовательский скрипт, который должен быть создан вне сервера vCenter.
Хотя это может показаться незначительной функцией, она определенно улучшает управление операциями для администраторов, позволяя им гарантировать оптимальную работу и не беспокоиться о том, что снимок виртуальной машины сохранится дольше, чем это требуется по политикам.
RSS
